AI Agent Identity: Treat Every Agent as a Privileged User

The move

Replace one shared agent credential with an attributable workload identity, a narrow scope matrix, and a tested revocation path. Route privileged tool calls through a broker that keeps upstream secrets outside the model’s context. Use that first agent as the rollout template; different providers will need different credential adapters.

The news, once: Portkey becomes part of Prisma AIRS

Palo Alto Networks announced its Portkey acquisition on April 30, 2026 and completed it on May 29. The releases position Portkey as the AI Gateway for Prisma AIRS. The completion announcement also describes agent identity security through Idira as part of the planned integration.

The useful operating principle is that an acting agent deserves the same identity discipline as any privileged workload: an accountable owner, bounded grants, revocation, and an audit trail. An acquisition announcement does not prove that a particular deployment enforces those controls. Test them at your own credential and tool boundaries.

Why acting agents changed the requirement

An agent with appropriate credentials can open a pull request, write to a bucket, apply a manifest, or message a customer. Without execution-level attribution, the provider may record only the shared account or person whose token it received. Identity links the initiating workload, delegated authority, and final action so you can restrict and investigate each one.

The gateway control plane can reject unidentified callers. Pair it with the sandboxes, approval gates, and egress restrictions in securing AI agents.

The runbook: AI agent identity from issuance to revocation

Choose one noncritical agent and one writable tool for the first rollout. Inventory its existing credentials and keep a documented recovery path before changing access. Steps 1 through 3 issue the identity and put the broker in the path; 4 through 7 keep it honest.

Step 1: one identity per agent, issued as a workload identity

Start with a stable principal for each workload or agent role, then bind each run and delegated child to a distinct execution ID. Do not create a service account for every message. SPIFFE uses workload IDs such as spiffe://corp.example/agents/platform/release-bot, proven with an SVID. Writing a URI in a registry does not attest it: the runtime and issuer must establish that binding.

Cloud federation exchanges runtime identity for temporary provider credentials. AWS STS, Google Cloud, and Microsoft Entra document their trust models. Restrict issuer, audience, subject, and workload attributes.

Separate automation from personal credentials. Background jobs should use a dedicated workload principal. Interactive tasks can legitimately use scoped user delegation where the provider requires it; record both the acting application and the authorizing user. Derive on_behalf_of from the authenticated delegation, never a caller-supplied username header.

Children get bounded delegation. Give each child an execution identity linked to its parent and an explicit scope subset. SPIFFE does not supply parent-child authorization semantics automatically. The broker must enforce them and handle parent revocation. Keep the identity credential in a trusted harness component; a model with unrestricted shell access can otherwise read its own process credentials.

# agents/release-bot.yaml — illustrative identity record, one per agent, in your registry
id: spiffe://corp.example/agents/platform/release-bot
owner: platform-oncall
attested_by: k8s://prod/ci/release-runner # the runtime proves it; no stored key
on_behalf_of: when-delegated # verified user or recorded job owner
children:
  allowed: true
  scope: subset-of-parent # never widen, never inherit by default
status: active # active | suspended | revoked

Step 2: design scopes per tool, and write the matrix down

Define scope per tool, verb, and resource. The following matrix is an illustrative policy target, not provider permission syntax or a claim that every provider supports these TTLs. Read and write are separate grants, minted separately, so a read-only session never holds a write credential.

Tool	Read scope	Write scope	Bound to	Grant TTL
Source control	contents:read on named repos	contents:write plus pull_requests:write; branch restrictions enforced separately	a repo list, never the org	60 min
Object storage	get on one prefix	put to artifacts/<agent>/ only	bucket plus prefix	15 min
Cluster	get and list in one namespace	apply in staging; nothing in prod	namespace	15 min
Database	read replica, one schema	none; migrations run under their own identity	replica host plus schema	per session
Chat and tickets	one channel	post to one channel; no DMs	channel ID	10 min
Model gateway	its own budget line	not applicable	model allow-list per agent	per call

GitHub App permissions are repository permissions; they do not themselves constrain a token to its own branch. Enforce protected refs with repository rules and the tool adapter. Likewise, channel and namespace restrictions need real provider or gateway enforcement. A write scope exists only where a named step in the agent’s job needs it, and that step’s name goes in the row. The matrix is a file in your repo that the broker reads, not settings someone once clicked; which control-plane layers stay in your own files is a decision this runbook leans on.

Step 3: broker credentials at call time, so the model never sees a secret

The broker resolves identity, scope, and provider credentials outside the model context. The harness authenticates to it using a bounded credential; the broker mints a temporary upstream credential or uses a protected static credential only for the authorized operation. These patterns are illustrative, not product-specific syntax.

References, not values. Tool configuration carries a pointer the broker resolves at egress, such as Authorization: Bearer ${secret:github/release-bot}. The model can read the pointer; outside the broker it is worth nothing.

Identity exchange at the gateway. The harness attaches the agent’s workload token in a header; the gateway verifies it, looks up the scope matrix, mints the upstream credential, injects it, and strips the agent token. Validate token signature, issuer, audience, expiry, and delegation before forwarding. Never accept a client-supplied identity claim without that verification.

# what the agent sends — illustrative
POST /repos/corp/api/pulls HTTP/1.1
Host: gateway.corp.example
Authorization: Bearer <workload-token>
# Delegation is derived from verified claims, not a username header.

# what GitHub receives — the gateway swapped the token; the agent never saw it
POST /repos/corp/api/pulls HTTP/1.1
Host: api.github.com
Authorization: Bearer <installation-token>
# Scope: two approved repos; provider expiry: one hour.

Process-scoped environment for MCP servers. An MCP server gets its credential from the broker at launch, as a scoped, short-lived environment variable, and its tools have no token argument at all; the model cannot pass a key through a slot that does not exist. A separate environment prevents accidental inheritance; it is not a security boundary against a same-user shell that can inspect processes or files. Put privileged adapters in a separate OS identity, container, or remote service with restricted IPC, mounts, and egress. Test access using the same shell capabilities available to the agent.

The agent talks to the broker; only the broker talks to the secrets. The audit line carries the credential’s ID, never the credential.

Step 4: minutes, not months

Choose the shortest provider-supported lifetime that fits the operation, and record renewal and failure behavior. Five-to-fifteen-minute workload tokens are a policy target where supported. AWS STS web-identity sessions have a 15-minute minimum; GitHub App installation tokens expire after one hour. The gateway can enforce a shorter local grant without changing the provider token’s expiry.

Refresh through the authenticated broker. If a SaaS tool supports only a static key, keep that key at the broker, use a bounded local grant, and document the provider rotation procedure. A short-lived wrapper does not make the underlying key short-lived or individually revocable. Protect the broker’s own signing keys and bootstrap credentials with platform identity or a managed secrets store, and test recovery after rotation.

Step 5: measure revocation at every boundary

Revocation is three hops, and you should know the latency of each.

1. Registry. One command flips the identity to revoked, no approval step for on-call, cascading to children by default.
2. Broker. It stops minting on the next request; measure status-cache propagation; under 10 seconds is an example local target, not a provider guarantee.
3. Gateway and providers. Deny new requests once the revocation is visible. A request already accepted upstream may still complete; cancel it only if the provider supports cancellation. Revoke minted credentials where supported and separately track those that remain usable until expiry.

# illustrative — whatever your registry calls it
agentctl revoke spiffe://corp.example/agents/platform/release-bot \
  --reason "token pattern found in transcript 2026-09-04T09:41Z" \
  --cascade children

Measure separate clocks: time to the first denied broker call, time until an already-issued upstream credential fails, and time until child work stops. Do not add them into one reassuring number. A provider token can remain valid long after the broker stops minting, and an accepted write cannot be undone by revoking its credential.

Run the drill on a noncritical workload with its owner and on-call aware of the scope. Revoke the parent, attempt a harmless read through the normal route, and probe a previously issued test token through an isolated provider check. Record errors, timestamps, remaining child executions, and any side effects. Set explicit service targets, such as new calls denied within 60 seconds and leaked token validity bounded by its actual expiry. Repeat after cache, provider, or delegation changes.

Step 6: tie every audit line to the identity

Every action carries the agent ID, the human it acted for, the session, the tool, the scope used, the policy version, and the credential’s ID. Never the credential itself.

{
  "ts": "2026-09-04T09:41:07Z",
  "agent_id": "spiffe://corp.example/agents/platform/release-bot",
  "parent_id": null,
  "on_behalf_of": "r.okafor",
  "session_id": "s_4f2c",
  "tool": "github.pulls.create",
  "scope": "pull_requests:write@corp/api",
  "credential_id": "cred_8a1e",
  "decision": "allow",
  "policy_ref": "gates.yaml@c0ffee"
}

Deny calls without a resolvable identity. Export the decision to controlled storage so you can query the agent, delegation, and scope independently of the vendor console.

Step 7: transcript hygiene, because keys leak sideways

These controls reduce paths by which secrets reach model context; logs, tool errors, files, and adapters can still leak them. A raw key in a transcript, a log, or a shared session export means something bypassed the broker, and the response is fixed: rotate first, because the leak is already a fact; redact second; find and close the path third. Scan transcript directories on a schedule for token patterns (ghp_, AKIA, sk-, eyJ) and add each new pattern to your vault rules. Treat those strings as candidates, not proof of a live key: prefixes can match harmless text and miss other credentials. Use a maintained scanner, restrict raw findings, and never paste values into tickets. What to scrub from an archive and what to keep is in the local-first vault.

What breaks, and how you’ll know

Shared accounts hide attribution. Investigate unexpected users, hosts, or executions under one principal. Multiple designed replicas may share a workload identity, but each run still needs an execution ID. A revocation drill should reveal exactly which work stops.

Long-lived tokens bypass the broker. An agent that works after revocation may hold a personal token in a dotfile, environment, or CI secret. Compare provider credential reports with your inventory and scan the relevant stores. Treat age as a review signal, not proof of compromise.

Children inherit authority. Parent IDs on every child call, absent execution IDs, and unchanged credential environments indicate missing delegation boundaries. Revoke a test parent and probe the children. The runtime approval problem applies here too: authorization must follow the call, including delegated calls.

The operating-layer frame: the org issues identity; the desk shows who ran as whom

Your organization owns the identity boundary: issuers establish principals, brokers scope credentials, gateways authorize calls, and durable logs record decisions. Local permission flags can complement these controls, but they cannot replace consistent enforcement across all paths. The test is whether an agent denied by policy can still reach the tool with an inherited credential.

At the desk, retain the run ID and verified identity reference alongside the task transcript. Automater’s supported local Library imports and fleet replay can help an operator find that recorded context; they do not infer authoritative identities or perform credential brokering. Correlate the transcript with the organization’s audit events, and redact any accidentally retained secrets. Explore Automater Lite for that local session workflow.

FAQ: AI agent identity

What is AI agent identity?

AI agent identity identifies the workload making a request and the execution responsible for it. An issuer or trusted runtime establishes the principal; authorization defines allowed resources and actions. Keep delegated human authority and parent-child relationships explicit so audit and revocation follow the actual chain of control.

Should an AI agent use a service account or a user account?

Use a dedicated workload identity for unattended automation. Interactive workflows may require scoped user delegation, which should name both the application and authorizing user. Avoid shared personal tokens. Bind each run to an execution ID, narrow its grants, and test whether revocation reaches the provider and delegated children.

How do I keep API keys out of an AI agent’s context?

Place a credential broker or protected adapter between the harness and upstream tools. Resolve secret references there, authorize each operation, and inject credentials outside model-visible arguments. Isolate that component from the agent’s shell and filesystem access; separate environment variables alone do not prevent the same user reading them.

Sources

• Palo Alto Networks — Portkey acquisition announcement (April 30, 2026)
• Palo Alto Networks — acquisition completion and integration scope (May 29, 2026)
• SPIFFE — workload identities, SVIDs, and trust domains
• AWS STS — web-identity exchange, session duration, and scope intersection
• Google Cloud — Workload Identity Federation
• Microsoft Entra — workload identity federation
• GitHub — installation-token permissions and one-hour expiry