The Agent Action Controls: what to put in place before an agent acts for your team

Most of the AI policies I see were written for people and typically include an acceptable-use policy, a list of approved tools, a vendor security review, and an AI council with Legal, IT, Security, HR and a few business unit leaders on it. That’s fine for what they’re doing today. But nothing in it says anything about an agent running in the background in the middle of the night.

TL;DR: The Agent Action Controls are five requirements every agent meets before it can write to one of your systems: a company-provisioned account, read separated from write with every action checked, one named owner per type of action, a single registry, and a log of every action, including refusals. They’re also what let you say yes to more agents. Put them in place while you have a handful, and “who changed this?” should take minutes to answer instead of weeks.

Why your AI policy doesn’t cover agents

Most governance work so far has gone into what I’ll call sidekicks: the AI tools people prompt, like Claude, ChatGPT and Copilot. Sidekick governance is mostly about keeping company data from leaking into the tool, so the policy covers what people paste, which tools are approved, whether the vendor trains on your inputs, and who gets a seat. Our own AI Governance Framework Template is that kind of document. It’s a fantastic place to start.

A background agent, on the other hand, runs inside your systems and only comes back to your team for the exceptions and the judgment calls. It can write to the vendor master, change payment terms, email customers, approve funds, call other agents and spend tokens on a corporate card. Governance for a background agent is about the actions it can and can’t take on your team’s behalf. Put the two side by side in a Venn diagram and the only real overlap is data access.

Ask for a list of every AI agent running in the company, who owns each one, and what each one can write to. The answer we’re starting to hear is “we’ll get back to you.” In Dataiku’s 2026 survey of 685 CIOs, 90% said they had complete tracking of their agents, yet 81% lacked complete oversight of agents built outside approved systems.

At one company we’ve seen, people built agents on a personal API key (the credential that lets software call an AI model) and shared it around. One person spun up a Supabase database because, from what I saw, their sidekick told them to. Three to five teams built agents for similar work, each on its own keys with its own prompts. Six months later, engineering or security found out and asked for an audit. Nobody could say which agents had acted for the company, whether any of those actions were approved, or which prompts were used. Engineering’s reaction was roughly: this is impressive work, but we have to rein this in.

For an agent, governance means being clear on who it’s acting as, what it can access, and how actions get approved and logged. Those answers live in your identity provider (the system that manages logins and permissions), your workflow design, your permission model and your logs. That’s why I think the policy of an organization describes the controls that exist as a result of engineering. The council decides what’s acceptable, and engineering makes it true.

A policy no control enforces is a wish.

1. Every agent acts as an account the company provisions

Every agent should run as its own account that the company provisions. No personal API keys and no admin accounts. You can see what each agent did and shut it off without touching anyone’s login. Access starts read-only, rises to an agreed scope only once the agent is in production, and the company can revoke it at any point.

In Gravitee’s October 2026 survey of organizations with 250 or more employees, only 17% gave each agent its own identity, and 14.2% ran agents on the deploying person’s own credentials. My partner Chris Monnat covered the other half: the context an agent needs to use that access well.

2. Read is separate from write, and every action gets checked

An agent that can read your CRM shouldn’t automatically be able to change it. Each write permission is approved by an admin who can revoke it, and the check happens every time the agent tries to act, not just when a run starts.

That check happens at one gate every call passes through: tool and model calls, secrets, outbound email, human approvals. The gate reads an allow list (the actions your team has permitted this agent) at runtime. An allowed action gets scoped credentials for that one call and is logged. A denied one stops before it reaches a system and is logged too. Change the list and the agent’s next action is held to it. OWASP’s agent security guidance agrees: “Enforce authorization checks at query time, not just at agent initialization.”

A gate only sees traffic routed through it (AWS scopes its own that way), so an agent on a personal key can go around it. That’s why control one has to hold first.

3. One named person owns each type of action

Every type of action an agent can take needs one named owner. Before you build an agent, write down where it can decide and where a named person decides. My rule of thumb is that agents do about 90% of the work and people about 10%, and the job is to name the person for each part of that 10% before anything gets built. That’s an individual, not a team, because that’s where clear accountability comes from. It’s the authority boundary from my September post, applied per action.

The CIO or CTO owns the agent governance layer, and the council keeps its role. Each type of action still has one named owner, and if nobody will own an agent, you turn it off.

Money is the clearest case. An agent never moves money on its own authority: a named person either approves each payment or sets the limit in advance, because the volume of work you save won’t offset the one time you get it wrong.

4. Every agent is listed in one registry

An agent registry is the list you didn’t have when someone asked: each agent’s purpose, owner, users, the systems it touches, and the version running.

Building it shows you what’s already out there. Start with your model provider’s admin console, which lists API keys. Then look for service accounts named with AI, bot or GPT, expenses with OpenAI or Anthropic, and third-party apps with access to company data, which Google Workspace lists and Microsoft 365 tracks too. That last check catches keys created on personal accounts, which a provider’s console misses. There will be more than you think.

The registry has to cover the agents you bought, too. If your sales, finance, help desk and customer success tools each come with their own agent and dashboard, you end up with a dozen agents from a dozen vendors, each handling permissions and logging its own way, with no single place to see who changed what. That’s sprawl too, and the registry is where it shows up.

5. Every action is logged, including the ones the agent was refused

Every agent action goes to an append-only, tamper-evident log, where entries can be added but not quietly edited or deleted. Include the actions the agent tried and was refused. The denials are some of your most useful data, because they show whether the process you think the agent follows is what it’s actually trying to do.

Run it as no log, no action: if the audit storage isn’t up, nothing gets dispatched. OWASP’s AI agent security cheat sheet says the same: “Fail closed when risk classification, approval validation, policy lookup, or audit logging fails.” That’s what lets risk and IT see the controls working instead of taking them on faith.

Putting the controls in place in about 90 days

Plan on about 90 days for the first workflow, assuming you already have an identity provider and a short list of action types.

• Weeks 1-2: find every agent, including the ones nobody approved.
• Weeks 2-3: add each one to the registry with a named owner. No owner, no agent.
• Weeks 3-5: set up three access tiers: a sandbox, a shared workflow tier and production. The sandbox gets limited credentials, tools and data, and a person who reviews what the agent does.
• Weeks 4-6: pick the first workflow for production, and name every action type and its owner.
• Weeks 6-10: run the agent in shadow mode: a real queue, no write access to systems of record, and a person reviewing what it would have done. The log shows where the two differ.
• Weeks 10-12: use that log to get written sign-off from risk and IT, with names on it, before the agent gets write access. The next workflow starts again with none.

After that, owners review their agents monthly: denials, where each behaved differently from the people doing the same work, and token cost. Reserve a budget for each agent call up front, deny calls that would exceed it, and retire agents nobody uses.

Why the controls let you run more agents

The Agent Action Controls are what let you say yes more often. The people closest to the work will have far more ideas for agents than a central AI function, and a shared platform with these controls lets you be more permissive in the sandbox. IBM’s 2026 study of 2,000 technology executives points the same way: organizations that build control into their AI systems deploy 16 times more agents than those relying on manual governance. It’s a correlation from a vendor that sells governance tools, so treat it as direction, not proof.

The pushback from a 300-person company: we have eight agents, mostly from vendors, and this sounds like enterprise overhead. My answer is a question. How many will you have in 90 days, and how are people setting up the next ones? The point is to avoid 50 agents you need to wrangle later. Start while it’s manageable.

It doesn’t happen on its own because nobody owns the plumbing. IT owns the identity provider, Security owns vendor review, Finance or RevOps owns the ERP and the CRM, and someone else builds the agents. The layer connecting them belongs to none of those, so nobody builds it.

That’s also why I think the council approach is so comfortable. No one on it actually has to own anything, and most people in the room don’t talk about that. These controls put a name on everything: each action type, each agent in the registry, every sign-off before write access. The council still decides what’s acceptable. The controls are where somebody’s name goes.

The end result is that every agent has one owner, and you should be able to answer “who changed this?” in minutes instead of weeks. Start with the list: every agent, its owner, what it can write to. If the answer is “we’ll get back to you,” you know what your first two weeks are for.