AI Agent Governance for Teams Without a Security Department

AI agent security and governance, for a team without a security department, comes down to one page of standing rules that everybody knows and somebody owns. It needs eight clauses: who may connect which agents, the list of approved tools, what data agents may touch, a named owner for every agent, the review rules, what records you keep, when access is revoked, and how the policy itself is reviewed. Written plainly, that fits on a page, takes an afternoon to agree, and answers the questions that otherwise get argued about each time somebody connects something new.

Policy, readiness and audit are three different things

It helps to be clear what this page is not. The readiness checklist is run once, before the first agent connects, and writes down what you intend. The monthly audit checks whether what each agent can do and did still matches. The policy sits between them: the rules that apply every day, to every agent, whoever connected it. Readiness produces the first version of the policy. The audit checks the team is following it. Without the policy, each audit has to rediscover what the rules were.

The eight clauses

1. Who may connect which agents

Decide whether anybody may connect an agent to team systems, or only certain roles. A common split for small teams: anyone may use an approved agent on their own work, and connecting an agent to a shared system, such as the code repository, the board or the customer inbox, needs the owner of that system to agree. Write down who that owner is for each system. The rule that matters is not who is allowed, but that the answer is written somewhere other than one person’s memory.

2. The approved tools list

A short list of the agents and connections the team uses, and for each one, what it is approved for. “Claude Code: coding in our repositories. Browser agent: research only, in its own profile.” Then a one-line route for adding to it: ask the policy owner, say what it is for and what it will reach, and it is added or not within a week. A list with no way on is a list people work around. OWASP’s agentic guidance↗ (opens in a new tab) has a name for the result, agentic supply chain risk, and the MCP version of the same problem is covered in MCP security risks.

3. What data agents may touch

Use three tiers, and name examples from your own business in each. Open: work agents may read freely, such as tasks, code and documentation. Careful: contracts, finances and plans, read only on a named person’s instruction for a named job. Never: credentials, payment details, customer and personal records, and anything under a regulation or contract. Add one line on where secrets live and that no agent reads that place. The practical settings behind this are in AI agent security best practices.

4. Every agent has an owner

Each agent connection has one named person who answers for it: they connected it, they know what it is for, they read what it did, and they revoke it when it is no longer needed. Keep a small register: the agent, its owner, what it is for, what it can reach, and the date it was connected. An agent nobody owns is the one still connected a year after the project ended.

5. Review rules

State what an agent may finish on its own and what a person must approve. The usual line: agents may read, search, draft, file and report; a person approves anything irreversible, anything customers will see, anything that spends money, and anything marked as finished. Put the rule in the agent’s own rules file too, so it is read every session, not just agreed in a meeting. Where exactly those approval points go is covered in human in the loop for AI agents.

6. Records

Name the records you keep and for how long. At minimum: each tool’s own history of changes with the agent named as the actor, version control for code, and the register from clause four. Add one habit that costs nothing: quote the work item’s reference in every commit message, so a change in the code can be traced to the reason for it. The case for a record kept by the tool rather than the agent is made in an audit trail for AI agents.

7. When access is revoked

List the triggers, so revoking is routine rather than a judgement call.

• The owner leaves the team or changes role. Revoke the same day.
• A device holding a credential is lost. Revoke at once, then rotate anything that device could reach.
• The agent has not been used for a month.
• The job it was connected for is finished.
• It did something outside its approved purpose. Revoke first, then investigate.

8. How the policy is reviewed

Name the policy owner, usually whoever already looks after access to the team’s systems. Review the page every quarter, and immediately after any incident or any new kind of agent being approved. Keep the old versions: when someone asks why a rule exists, the history answers.

The page itself

AI agent policy - <team> - version <n>, <date>
Policy owner:   <person>; reviewed quarterly and after any incident

1 Connecting    Own work: any approved agent. Shared systems: ask the
                system owner (code: <person>, board: <person>, inbox: <person>)
2 Approved      <agent> - approved for <purpose>; <agent> - <purpose>
                New tool: ask the policy owner, say what it is for and reaches
3 Data          Open: <examples>. Careful: <examples>, named job only.
                Never: credentials, payment data, customer records
4 Owners        Every connection has one owner; register kept at <place>
5 Review        A person approves anything irreversible, customer-facing,
                paid for, or marked finished
6 Records       Tool histories; version control; ref in every commit
7 Revoke        Owner leaves; device lost; unused 30 days; job done;
                outside purpose (revoke first, then investigate)
8 This page     Kept at <place>; old versions kept

Keep the page where the team keeps its work, not in a folder nobody opens. If your agents read a shared notes file before they start, put clauses three and five there as well, so the agents follow them too.

If someone asks about frameworks

A customer or an investor may ask whether you follow a recognised framework. Two come up most, and it is worth knowing their shape so you can answer honestly.

• The NIST AI Risk Management Framework↗ (opens in a new tab) (AI RMF 1.0), released in January 2023, is voluntary. It is organised around four functions: Govern, Map, Measure and Manage. NIST added a Generative AI Profile, NIST AI 600-1, in July 2024.
• ISO/IEC 42001:2023↗ (opens in a new tab) specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. It follows the same structure as other ISO management-system standards such as ISO/IEC 27001, and organisations can be certified against it.

A one-page policy does not make you compliant with either. What it does is give you written rules, named owners, records and a review cycle, which are the things any framework will ask to see first. For the security risks themselves, OWASP guidance on AI agents is the most practical starting point.

Signs the policy has stopped working

• The audit keeps finding connections that are not on the approved list.
• Nobody can say who owns a particular agent.
• Revoking happens only after something goes wrong.
• The page has not changed in a year, while the agents you use have.

What fenbs enforces for you

Some clauses are easier when the tool does the enforcing. On fenbs, roles are defined per company from plain-language permissions, and a board role can only narrow the company role. An assistant connects with its own token and holds the role of the person who connected it, narrowed by the scopes read, write and comment, so clause one is a role setting rather than a promise. Settings, “Connect an AI assistant”, lists each token by name with its scopes and when it was last used, which is most of the register in clause four, and the Your connections page shows every board an assistant acting as you could reach. History records every change with who made it, an assistant’s as “Claude via” its person, for clause six. Revoking is one click and leaves the person signed in, for clause seven. And AI context notes are where clauses three and five go, so every assistant reads them before it starts.