AI Agent Governance in 2026: Identity, Kill Switches and Cost Caps
AI agents now touch money, customer data and production code. Here is a vendor-neutral 2026 checklist — identity, least privilege, isolation, kill switches and cost caps — for running them safely.
AI agents have moved from demos into systems that touch money, customer data and production code. Governance hasn't kept up. In a single day this week (27 October 2026), IBM, Salesforce, SAP, Oracle and Akamai all announced controls for AI agents. The same day, an EY survey reported that AI leaders see fast deployment pushing staff to work around governance. When five platform vendors ship the same category of feature at once, the market is telling you something: running agents without identity, limits and an off switch is no longer acceptable.
This guide turns those announcements into a vendor-neutral checklist you can apply whatever stack you run.
Why agent governance became urgent
A chatbot answers questions. An agent acts: it calls APIs, writes records, runs code and spends tokens. That changes the risk profile in three ways.
- Agents multiply quickly. IBM's announcement cites a Gartner estimate that the average Fortune 500 company will run more than 150,000 agents by 2028. Few teams can name every agent they run today.
- Agents fail quietly. Salesforce's framing is blunt: agents can give wrong answers and run up costs before anyone notices.
- Agents inherit too much access. Many early agents run on a shared service account or a developer's personal token. That means broad, long-lived permissions with no clear owner.
If your organisation has moved AI from proof of concept to production, these gaps are now operational risks, not theory.
The five controls every production agent needs
1. A real identity and a named owner
Treat every agent as a non-human identity, like a service account, but stricter. Each one should have:
- a unique ID, not a shared credential
- a named human or team owner who is accountable for what it does
- a written statement of purpose (what it is allowed to do, and for whom)
IBM's new Agent Identity, now generally available alongside HashiCorp Vault 2.2, follows this model: it records who owns each agent and what authority it holds. You don't need a specific product to adopt the pattern. An agent register in your existing IAM or CMDB is a reasonable start.
2. Least-privilege, short-lived access
An agent should get only the permissions its current task needs, for only as long as it needs them.
- Issue scoped, expiring credentials instead of static API keys.
- Separate read and write permissions, and add human approval for irreversible actions (payments, deletions, outbound messages).
- Make access revocable in real time, so a session can be cut the moment an agent goes outside its approved scope.
This is where agent governance overlaps with RAG security and data governance: an agent that can retrieve sensitive documents needs the same access rules as the people it serves.
3. Isolation for anything that runs code
Agents that write and run code need a sandbox. This week Akamai launched Agent Sandbox, which uses WebAssembly isolation to cap compute, memory, outbound connections and system access. IBM previewed isolated sandboxes with a kill switch in watsonx Orchestrate. The isolation approaches in use include microVMs, policy-enforced containers and WebAssembly functions. Which one fits depends on your workload. Running agent-generated code with no isolation at all doesn't fit any of them.
4. Continuous evaluation and a kill switch
Testing an agent once before launch isn't enough. Models, prompts, tools and the APIs agents depend on all change over time.
- Before deployment: run task-level evaluations against agreed quality thresholds.
- In production: keep scoring live behaviour against the same thresholds.
- When quality drops: trigger a predefined response, such as falling back to a human, narrowing permissions, or shutting the agent down.
Salesforce's update to Agent Fabric follows this loop: Agent Evals and API Evals detect regressions (both in beta from November 2026), and an Agent Kill Switch, generally available now, can stop the agent. Our guide to LLM evaluation in production covers how to design those thresholds.
5. Hard cost limits
Without spending caps, an agent stuck in a loop can burn through a monthly budget in hours. Set:
- per-agent and per-team token budgets, with hard stops rather than just alerts
- cost attribution for every agent, so spend links back to an owner and a use case
- caching and response trimming where quality allows (Salesforce says its new optimisation policies cut token use by up to 75% in test scenarios. Treat that as a vendor test figure, not a benchmark.)
Cost data also feeds directly into measuring AI ROI: if you can't attribute spend to each agent, you can't prove any agent is worth running.
Shared business context: the overlooked control
Some agent failures aren't security problems at all. They happen because the agent misreads the business. If "active customer" means different things in finance and marketing, an agent will confidently report the wrong number. Oracle's new AI Data Platform features target this with shared ontologies and a semantic layer, so agents use the same definitions of entities, metrics and policies. Whatever your platform, write down your key business definitions before you let agents reason over them.
Vendor control plane or your own?
SAP is adding an agent gateway and an enterprise AI gateway. Salesforce, IBM and Oracle each offer a control plane. The strategic question is where governance lives:
- In the vendor's platform: faster to adopt, but harder to apply consistently once your agents span several clouds and SaaS tools.
- In your own layer: more work up front, but one set of policies across every agent.
Most enterprises will end up with a mix. Decide deliberately, using the same logic as any AI build vs buy decision, rather than letting each team's tool choice decide for you.
A 30-day agent governance starter plan
- Week 1, inventory: list every agent in use, along with its owner, purpose, credentials and data access.
- Week 2, access: replace shared and static credentials with scoped, expiring ones, and add human approval for irreversible actions.
- Week 3, controls: add sandboxing for agents that run code, set budget caps, and test that the kill switch actually works.
- Week 4, evaluation: set quality thresholds, start production monitoring, and agree who responds when an alert fires.
Need help putting agent governance in place without slowing delivery? Talk to rowth.ai's enterprise AI consulting team.
Frequently asked questions
It's the set of controls that decides what an AI agent can access, what it may do, who is accountable for it, and how it is monitored, limited and shut down when it misbehaves.
Chatbots mostly produce text. Agents take actions, such as calling APIs, changing records and running code, so identity, permissions, isolation and spending limits matter far more.
Not to start. An agent register, scoped credentials, budget caps and a tested kill switch can be built on your existing IAM and observability tools. Platforms help most once you're running agents at scale across several vendors.
It's a predefined way to stop an agent immediately, either by a person or automatically when quality, security or cost thresholds are breached. Test it before you need it.
Start with an inventory. You can't govern agents you can't see, and most organisations find more agents, and broader access, than they expected.