Key Takeaways
- Securing an AI agent means bounding what one identity can reach, because the agent picks its next tool at runtime.
- An agent is not a service account. Its permissions follow from what it might decide at runtime, which code review cannot enumerate.
- Attribution is the record everything else rests on, so each action needs a log naming the agent, the human, and the tool.
- Provider agent-identity services now issue per-agent credentials with short lifetimes, replacing the shared service account key as the default.
- Orca maps the workloads, identities, keys, and sensitive data behind an agent without installing software, so a permission stops being a hypothetical.
Securing an AI agent means bounding what one identity can reach at the moment it acts. An application’s behavior is fixed when its code ships. An agent holds a credential, chooses its next tool at runtime, and acts between the request and the result.
This article treats one agent as a security object. Four properties decide whether it stays safe: the identity it holds, the credentials behind it, and the tools it can call. The fourth is what happens to all three at retirement.
The phrase itself carries two readings. Some readers arrive wanting to secure agents. Others want agents that do security work. The first section separates them.
Understanding AI Agents Security
The phrase does two jobs at once. One group wants to secure the agents their organization deployed. The other wants AI agents for cyber security, meaning agents that investigate findings and automate analyst work.
This article covers the first job, and the section on security operations covers where the two meet. A second vocabulary problem sits underneath, because the word agent also names software installed on a workload to collect telemetry. The split between AI agents, security agents, and agentless scanning settles that one.
What Makes an Agent Different From an Application
Three properties separate an agent from the application it replaced. It holds an identity of its own, so its actions carry a subject. It selects which tool to call at runtime, so its permission set cannot be read off its source code. It sits between the request and the result, so an instruction that reaches it can become an action taken with valid credentials.
OWASP describes agents as systems that “reason, plan, use tools, maintain memory, and take actions to accomplish goals.” Google DeepMind’sAI Control Roadmap gets to the same place throughthreat modeling. It treats an untrusted internal agent like “a potential rogue employee who already has access to the office.” Both framings put identity and reach ahead of model behavior, which is the order this article follows.
Key Security Risks of AI Agents
The AI agents security risks worth ranking attach to the agent itself. Each one below names a mechanism and what the fix costs.
- An inherited credential wider than the job. Agents launch with the permissions of the engineer or pipeline that created them, because that is the shortest path to a prototype. Derive a permission set from the tool list, then remove the rest. Budget for breaking the agent once and finding calls nobody documented.
- Secrets reachable from the agent’s runtime. A key in an environment variable, a mounted config file, or an instance metadata endpoint is reachable by anything in that process. Secrets detection is the cheap half of the fix, and rotating the key across every consumer is the rest.
- A tool registered wider than its purpose. OWASP contrasts a shell tool with allowed_commands set to * against a file reader scoped to /app/reports/*. The scoped version permits read operations only and blocks *.env, *.key, *.pem, and *secret* by pattern. Writing that allowlist is the whole cost.
- Context and memory that persist across sessions and users. OWASP names memory poisoning as a distinct risk, because content written into memory once shapes later sessions, including other people’s. Isolation per user plus an expiry is cheap early and painful to retrofit. The protocols that carry agent memory and context bring their own exposure.
- The dependency and skill supply chain behind the agent. Skills and connectors are code you did not write, running under your agent’s identity. Orca researchers documented supply chain attack vectors in an agent skills marketplace.
- Reachable data the identity opens without being asked. A read role on a bucket stays a read role whether or not a prompt mentions it. Run attack path analysis from the agent’s role to your most sensitive store. Scope the role, because a prompt filter sits at the wrong layer for this one.
AI Agents and Identity Security
AI agents and identity security meet where a working identity process stops working. That process assumes the caller is predictable. This section stays on a single agent. The questions are what it is, how it gets issued, what it authenticates as, and how it is retired.
Four lifecycle events decide whether an agent stays inside its bounds: issuance, scoping, rotation, and offboarding. Offboarding is where estates fail, because a decommissioned agent stops running long before its credential stops working. The disciplines are ones you already run, so apply cloud least privilege and entitlement management here.
Why an Agent Is Not a Service Account
A service account performs a fixed set of operations, so its permission set follows from its code. An agent decides at runtime, so its permission set follows from what it might decide. Same credential type, different bounding problem.
Providers now encode that difference in the identity object. Microsoft describes an agent identity as “a special service principal in Microsoft Entra ID” that “doesn’t have credentials on its own.” A separate blueprint object holds the credentials and acquires tokens for it. Google’s Agent Identity gives each agent a SPIFFE identifier and an X.509 certificate valid for 24 hours.
Google states that agent identities “can’t be impersonated, and don’t allow developers to generate long-lived service account keys.” That closes the shared service account key problem at the identity layer.
Attribution and the Audit Record
An action taken by an agent needs three names in the log: the agent, the human it acted for, and the tool it used. With fewer than three, a review can establish that something happened and never who answers for it.
The identity systems now carry this. Entra issues user tokens with a split subject and actor: “The subject of the token is a user, while the actor is the agent identity.” Google states that when an agent acts on a user’s behalf, logs show both identities. Wire your audit logs to keep the actor field before you need it.
Two neighboring bodies of work cover the rest. The OWASP Non-Human Identities Top 10 catalogs the machine identity failures an agent inherits. Identity threat detection for the cloud covers what to do once an identity behaves unlike itself.
Impact of AI Agents on Security Operations
The impact of AI agents on security operations runs in two directions. The first direction returns work. Agents draft enrichment on a finding, collect evidence a reviewer would have gathered by hand, and open a case before a person does. Vendors sell this as soc AI agents security operations automation, and the analyst hours it returns are real.
The second direction is the reason you are reading this page. Security AI agents hold credentials into your ticketing system, your cloud accounts, and your log store. An agent that reads security telemetry is worth compromising, so AI threat detection programs have to account for the agents inside them. Every practice below applies to those agents too.
Authentication and Authorization Frameworks for AI Agents
Framework here means the authentication and authorization machinery an agent runs on, not a control framework with domains and control identifiers. Two questions get answered at call time: how the agent proves who it is, and how far its token stretches.
Delegated Authority Without Privilege Escalation
An agent acting for a user must not exceed that user’s own authorization, and default configurations rarely enforce it. Token exchange is the protocol answer. RFC 8693 separates impersonation from delegation.
Under impersonation, “A is B within the context of the rights authorized by the token.” Under delegation, “A still has its own identity separate from B,” and the issued token names both parties. Delegation is what you want, because the record survives the call. The specification’s may_act claim “makes a statement that one party is authorized to become the actor and act on behalf of another party.”
An authorization server checks that claim before agreeing to the exchange. Amazon exposes the pattern in Bedrock AgentCore Identity as an on-behalf-of exchange with a TOKEN_EXCHANGE grant type.
Credentials, Tokens, and Lifetimes
Where the agent’s own credential lives decides the rest. Google auto-provisions a per-agent X.509 certificate and binds access tokens to it, so a stolen token is not replayable outside its runtime. Microsoft keeps credentials off the agent identity and holds them on the blueprint that requests tokens. Both replace the long-lived key a shared service account carries.
Read the caveats on your provider’s path before relying on it. AWS documents a user-ID-based path when an agent requests a workload access token by user identifier. AWS states that “the platform treats the userId as an opaque string and cannot verify it against an authenticated end-user identity.” It recommends an explicit IAM deny on that action for workloads that always have a JWT available.
| Mechanism | What it bounds | What it does not bound |
| Per-agent workload identity | Which principal the action is attributed to | What that principal is allowed to reach |
| Audience-scoped token | Which service accepts the token | What the agent does once that service accepts it |
| Short credential lifetime | How long a stolen token stays useful | Damage done inside the validity window |
| Token exchange with delegation | Whose authority the call runs under | Whether that authority was already too broad |
| Per-tool authorization check | Which tool the agent may invoke | The arguments passed to a permitted tool |
| Approval step on a named action class | Execution of high-impact operations | Actions the policy never classified |
No row above is a boundary on its own. The pairing that carries the most weight is a per-agent identity plus a per-tool check. One names the actor and the other limits the verb. Teams already running Open Policy Agent can express the second as policy instead of application code.
Best Practices for Securing AI Agents
The OWASP AI Agent Security Cheat Sheet lists nine practice areas, and seven apply to a single agent. Two belong elsewhere, since output validation sits with the guardrail layer and multi-agent security starts once one agent can call another. Each practice below states what it leaves uncovered.
- Tool security and least privilege. Scope each tool to the narrowest operation and resource path that finishes the job. Deny anything the allowlist does not name. It does nothing about a harmful argument passed to a permitted tool.
- Input handling on retrieved context. Treat retrieved documents, API responses, tickets, and commit messages as untrusted, since the user prompt is not the only input an agent reads. The wider set of LLM risks and defenses covers the injection mechanics. Content carrying no recognizable pattern still gets through.
- Memory and context hygiene. Isolate memory per user and per session, set an expiry and a size cap, and screen content before it persists. Data the agent legitimately read this session is still in play this session.
- Approval steps on high-impact actions. OWASP is specific: separate decision from execution, and bind approval to the exact action. The record holds the actor, tool name, target resource, normalized parameters, timestamp, and expiry. Fail closed when risk classification, approval validation, policy lookup, or audit logging fails, and accept that an unclassified action never reaches the step.
- Monitoring and observability of tool calls. Log each tool call with its arguments and result, then alert on call rate, repeated denials, and first use of a sensitive tool. DeepMind measures its own monitoring on coverage, recall, and time-to-response, which beat an alert count as targets. Behavior inside an unlogged call stays invisible.
- Data classification and handling. Classify what enters the agent’s context and apply a handling rule per class. Restricted data gets redacted before it reaches a prompt, a log, or an output. Classification says nothing about what an aggregate of permitted facts reveals.
- Adversarial testing. OWASP says agents should be tested “before production deployment and after material changes to prompts, tools, memory, retrieval, policies, or model providers.” Keep repeatable abuse cases for tool misuse, privilege escalation, memory poisoning, data exfiltration, and approval bypass. The point cuts both ways for AI agents in security testing, since an agent running offensive tooling is the last one that should ship untested.
Compliance and Governance in AI Agent Deployment
Governance for an agent you approved on purpose starts as a records problem. Four records carry it, and three already exist elsewhere in your environment.
- Deployment approval record. States what was reviewed, by whom, and against what criteria.
- Audit evidence. Draws on three sources you already have: the attribution record, the tool inventory, and the authorization configuration on the identity.
- Owner record. Answers the question that stalls governance discussions. An agent cannot be accountable, so a named human is the control.
- Change-review record. Tracks changes to the agent’s model version, prompt, or tool list, since any of them can materially change its behavior without shipping new code.
Microsoft encodes ownership as a sponsor field, “which records the human user or group that’s accountable for an agent.” It exists so somebody can be reached when an incident happens.
Where the agent runs shapes what evidence you can collect, which makes the choice ofAI agent runtime platform a governance decision. For systems the EU AI Act classifies as high risk, Article 12 turns that logging record into a legal obligation. Such systems must “technically allow for the automatic recording of events (logs) over the lifetime of the system.”
How Orca Secures the Cloud Estate Your AI Agents Run In
Orca does not sit inside an agent’s reasoning loop. It does not inspect tool calls before they execute or decide whether an action is in policy. Those controls belong in the application, next to the agent. The layer underneath carries most of this article’s risks, and that layer is Orca’s.
Orca’sAI security posture management builds a complete AI inventory and bill of materials for every AI model deployed in your cloud. It alerts on overprivileged permissions and internet exposure, detects keys and tokens to AI services left in code repositories, and uses the Unified Data Model with agentless SideScanning™ to map identities, assets, network paths, and sensitive data. That gives teams the context to prioritize real exposure. Get a demo to see what the identities behind your agents can actually reach.
Frequently Asked Questions about AI Agents Security
What Are the Biggest Security Risks of AI Agents?
Rank them by what survives when the agent is idle. A prompt injection needs a live session. An over-scoped credential keeps working while the agent sleeps. That ordering puts everything attached to the credential ahead of everything attached to a conversation.
Can You Run an AI Agent With a Read-Only Identity?
Often, and it is the cheapest control available. A research or reporting agent that reads and drafts needs no write path at all. The limit appears when someone asks it to file the ticket it drafted, and the answer there is a second identity holding one write scope. Read-only does nothing about data exposure, since reading is the whole risk in that direction.
How Do You Decommission an Agent Safely?
Revoke before you delete, and verify against the credential by disabling the identity and confirming its tokens now fail. Then remove the tool registrations, the memory store, and any object that could reissue a credential. Deleting the deployment first leaves a working credential with nobody watching it. Keep the audit records, because the agent’s history outlives the agent.
Do Agents Used for Security Testing Need Different Controls?
They need the same controls held tighter. An agent running offensive tooling has a legitimate reason to make requests that look like an attack, which removes your easiest detection signal. Scope it to a target list and run it under an identity that cannot reach production data. Record the authorization for each engagement, because what changes here is the blast radius.
What Changes When an Agent Runs on a Third-Party Platform Rather Than Your Own Cloud?
The control point moves outside your account. Your agent authenticates to your systems through a grant somebody approved once, so the scope on that grant becomes the boundary. Ask what the platform logs, how long it keeps those logs, and whether you can export them. Some platforms answer well, and others are still writing the documentation.