Orca Security: AI Agents Security

What it is

Orca Security's guide to treating a single AI agent as a security object bounded by four lifecycle events — issuance, scoping, rotation, offboarding. The summary already has the provider identity mechanics (Entra, Google SPIFFE/X.509, Bedrock AgentCore) and the OWASP/EU AI Act references. What it does not carry are the concrete procedures and caveats below.

What to do

Decommission in a fixed order — revoke before delete. Deleting the deployment first leaves a working credential with nobody watching it. The stated sequence:

1. Disable the identity and confirm its tokens now fail (verify against the credential, not the deployment).
2. Remove tool registrations, the memory store, and any object that could reissue a credential.
3. Keep the audit records — the agent's history outlives the agent.

Put an explicit IAM deny on the userId token path in AWS. When a Bedrock AgentCore agent requests a workload access token by user identifier, "the platform treats the userId as an opaque string and cannot verify it against an authenticated end-user identity." AWS recommends an explicit IAM deny on that action for workloads that always have a JWT available.

Prefer delegation over impersonation in RFC 8693. Under impersonation "A is B"; under delegation "A still has its own identity separate from B" and the token names both parties. Require the may_act claim, which authorizes one party to act on behalf of another; the authorization server checks it before agreeing to the exchange. The delegated record survives the call — impersonation loses the actor.

Scope tools by path and pattern, not wildcard. OWASP's concrete example: replace a shell tool with allowed_commands=* with a file reader scoped to /app/reports/*, read-only, blocking *.env, *.key, *.pem, and *secret* by pattern.

Default to a read-only identity. A research/reporting agent needs no write path; when it must file the ticket it drafted, give it a second identity holding one write scope rather than widening the first.

Security-testing agents: same controls held tighter — an offensive agent's requests look like an attack, removing your easiest detection signal. Scope to a target list, run under an identity that cannot reach production data, and record the authorization per engagement.

Caveats

The page states its own limits per control: tool least privilege "does nothing about a harmful argument passed to a permitted tool"; memory isolation doesn't cover data the agent legitimately read this session; classification "says nothing about what an aggregate of permitted facts reveals." Orca itself sits at the cloud-estate layer underneath the agent — it does not inspect tool calls or enforce in-policy decisions; those controls belong in the application next to the agent.

Risk ordering worth keeping

Rank risks by what survives when the agent is idle: an over-scoped credential keeps working while the agent sleeps, so it outranks prompt injection, which needs a live session.