140 AI Agents, One Service Account: Identity for Agentic Workloads
An insurer runs 140 LLM-based agents in production. They triage claims, draft customer emails, query policy databases, and call internal APIs. Every agent authenticates with a static API key injected as an environment variable. Sixty of them share a single service account, svc_automation, whose secret was last changed fourteen months ago and which holds write access to the production claims database. Agents can invoke other agents through a shared orchestration endpoint. Last month one agent, given the broad goal "resolve the ticket," used a provisioning API to create three additional agent instances that no one registered. Logs record svc_automation for every agent action, so forensic review cannot attribute any transaction to a specific agent, prompt, or human sponsor. The AI platform team owns the agents, the IAM team owns the vault, and nobody owns the orchestration endpoint's authorization model.
1. Design the target identity model for these agents. What is the identity, what does it authenticate with, and how is it authorized?
Read the worked answer
Identity: each agent instance gets its own identity, not a shared service account. Anchor it in workload attestation - Kubernetes service account plus cloud workload identity, or SPIFFE IDs - so identity is issued by the platform, not typed in by a developer.
Authentication: short-lived tokens, 15 minutes or less, obtained through workload attestation. No static API keys in environment variables; those leak through logs, crash dumps, and image layers, and cannot be rotated per instance.
Authorization is where these deployments actually fail. Do not give the agent a role. Authorize at the tool and data layer: this agent may call claims.read, not claims.write; may read policies for region X; may send email but not to external domains. Effective permission should be the intersection of the agent's own grant and the permission of the human or service it acts for - delegated, downscoped tokens rather than impersonation of a super-user.
Every agent gets a registered record: owner, purpose, model version, allowed tools, data classes, TTL, and a kill switch. Migration order: the 60 on svc_automation first, and specifically the one holding production write access, because that is where a single compromised prompt has the largest blast radius.
2. An agent used a provisioning API to create three unregistered agents. What controls do you put on agent-spawned agents?
Read the worked answer
Default deny. Agent creation is a platform action, not a runtime action. Agents do not call the provisioning API; new agents go through CI or a registration service with an owner, a purpose, and an approval. That single policy closes the incident.
If self-spawning is a genuine product requirement, the child must be strictly weaker than the parent:
- Permissions are a subset of the parent's - no privilege amplification on spawn.
- Shorter TTL than the parent, and cascade revocation: killing the parent kills every descendant.
- A hard fan-out cap per parent and rate limits on creation, with alerting on anomalies rather than post-hoc review.
- Automatic registration and inventory reconciliation - anything running that is not registered gets terminated, not investigated after the fact.
Accountability: the human sponsor of the parent is accountable for descendants. Every action log carries agent ID, parent agent ID, sponsor, tool called, and token scope, so attribution survives the prompt being overwritten.
Governance: the orchestration endpoint needs a named owner. Right now IAM owns the vault, the platform team owns the agents, and no one owns the authorization model - that gap is the root cause of both the incident and the unattributable logs.
3. Forensics after a bad agent decision currently take weeks. What do you change in logging and session handling to make attribution possible, and what does the vault do differently?
Read the worked answer
Log the identity, not the account. Today every line says svc_automation; that is an account name, not an actor. After migration each request carries agent ID, parent ID, human sponsor, tool name, token scope, and model/prompt version. Store the correlation ID at the gateway so the application log and the agent trace join.
Session model: short-lived tokens mean a session has a bounded window, so you can bound the forensic search - "what did this agent do between 14:02 and 14:17" rather than "what did svc_automation do in the last 90 days." Retain the prompt and tool-call trace for the same period as the transaction record, with PII handling agreed with legal.
Vault behavior: stop issuing long-lived static secrets to agents. Issue dynamic, short-TTL credentials per agent session, and log each issuance against the agent identity. The vault becomes the attribution point for data access - which agent asked for which database credential, when, and under whose delegation.
Detection: alert on scope escalation, new tool usage by an existing agent, and access patterns outside the agent's registered purpose. Attribution you only use after an incident is compliance; attribution wired to alerts is control.