AI agent security is not just model security. The dangerous moment is when a model can use a credential, call a tool, read sensitive data, or write into a system of record.
That means security design has to move closer to workflow design. An agent that drafts a renewal brief needs different controls than one that changes a contract field, refunds an order, updates payroll data, or sends instructions to a customer. The model may be the same. The blast radius is not.
Do not give an agent a human's all-purpose account
Agents need named identities, narrow scopes, reviewable tool calls, and revocation paths. Shared credentials hide accountability at exactly the wrong moment.
Start with identity
Every production agent needs a durable identity. That identity should answer four questions:
- Which workflow is this agent allowed to perform?
- Which user, team, or service initiated this run?
- Which systems can the agent access?
- Which actions require a human authority separate from the agent?
When teams skip this, they usually connect the agent through a broad admin token or a helpful employee’s account. That might speed up a prototype, but it destroys accountability. Logs show the wrong actor. Permissions are broader than the workflow. Offboarding and rotation become unclear. An incident investigation starts with “whose credential was this?”
The NIST AI Risk Management Framework points teams toward governance and measurement across the whole AI system. For agent security, identity is the first governance primitive: without a named workflow identity, the team cannot map risk, measure behavior, manage incidents, or prove who authorized an action.
Bound the tools before you tune the model
Tool access should be designed as a set of verbs, not a pile of integrations. For example, “read account summary,” “draft renewal note,” “request approval,” and “update next-step field” are different permissions. They should not all ride through one CRM credential.
flowchart LR
A["Agent identity"]
A --> B["Read scopes"]
A --> C["Draft scopes"]
A --> D["Approval scopes"]
A --> E["Write scopes"]
E --> F["Rollback path"] OWASP’s LLM Top 10 names the risks that become concrete when tool use is automatic: prompt injection, sensitive information disclosure, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, and unbounded consumption. These are not theoretical when an agent can call APIs. Tool boundaries are the place where those risks become denied actions, approval gates, rate limits, and audit events.
The security control plan
AI agent security control plan
Converts agent security from a vague checklist into concrete controls attached to the workflow.
Control surface: Authentication
- Design decision
- Use a named agent identity with workflow-specific credentials, rotation, and revocation
- Failure it prevents
- Untraceable actions through shared human or admin accounts
Control surface: Authorization
- Design decision
- Create separate read, draft, approve, write, and admin scopes for each connected system
- Failure it prevents
- One broad token turning a narrow workflow into wide system access
Control surface: Data boundary
- Design decision
- Limit retrieved fields, mask sensitive values, and log references instead of raw payloads
- Failure it prevents
- The agent or its logs becoming a second uncontrolled data store
Control surface: Approval gate
- Design decision
- Require human approval for financial, legal, customer-facing, destructive, and irreversible actions
- Failure it prevents
- A plausible generated answer becoming an unauthorized business action
Control surface: Blast radius
- Design decision
- Set per-run, per-record, per-customer, and per-time-window limits with automatic halt conditions
- Failure it prevents
- A bad instruction or integration bug scaling across the business before anyone notices
Treat untrusted context as an input risk
Many agent workflows read email, tickets, documents, webpages, chat logs, or user-submitted attachments. Those are untrusted inputs, even when they live in trusted systems. A document can contain instructions that try to override system behavior. A support ticket can include hidden text. A webpage can tell the agent to exfiltrate data.
The security model should separate business content from agent instructions. Retrieval should label source, owner, freshness, and trust level. Tool calls should be validated against policy, not just model intent. High-risk outputs should be checked before another system treats them as instructions.
IBM’s Cost of a Data Breach Report puts a price on loose access: the global average breach cost is $4.4M, and 97% of organizations reporting an AI-related security incident lacked proper AI access controls. For AI agents, the cheapest control is often a smaller permission, a clearer approval path, and a faster revocation route.
Design for containment
The security team should be able to stop one workflow without shutting down every AI use case. That means agents need isolated credentials, feature flags, per-tool kill switches, audit events, and rollback procedures.
Metacto Continuous AI Operations treats this as part of running production AI: monitor behavior, evaluate outputs, manage model, prompt, and context changes, review incidents, maintain runbooks, and improve controls in monthly reviews. Security is not complete at deployment. It is exercised every time the agent touches a real system.
The test is simple: if the agent follows a bad instruction, how far can it get before a control stops it?