Part 2: Non-Human Identity for Autonomous Agents

Part 1 established the Helios reference architecture and explicitly assumed a credential broker sat behind the Tool Gateway, quietly handing out access whenever a policy check passed. That assumption does not survive contact with a real deployment. If the broker issues a long-lived IAM role or a static API key to every agent task, you have simply rebuilt the service-account sprawl problem that plagued CI/CD a decade ago — except now the principal calling those credentials is a non-deterministic reasoning loop capable of chaining twelve tool calls autonomously. Non-human identity for agentic systems cannot mirror human IAM patterns; it needs per-task, per-call, cryptographically attestable identity that expires before an attacker can pivot on it.

#Problem Statement: Static Credentials Do Not Fit Agentic Blast Radius

A conventional service account bound to an EC2 instance role or a Kubernetes ServiceAccount token typically lives for hours, sometimes indefinitely. That is tolerable when the caller is a deterministic microservice with a known, auditable code path. It is not tolerable when the caller is an LLM-driven orchestrator that can be steered off-script by a malformed observation or a prompt injection payload buried in a fetched document. If the Tool Gateway’s broker hands out a role with s3:* on a bucket for the lifetime of the agent’s container, a single hallucinated argument or injected instruction can exfiltrate the entire bucket before the Action Ledger even finishes writing the entry.

The correct model treats every reasoning step as its own non-human identity with its own credential lifecycle. Scoping must happen at the level of the individual tool call, not the agent process, and the credential must die at or before the moment the HTTP response returns.

#Architectural Breakdown: Non-Human Identity for Ephemeral Agents

#SPIFFE/SPIRE as the Root of Trust

Helios uses SPIFFE to issue a workload identity to the Agent Orchestrator process itself, distinct from any downstream credential. The SPIFFE ID encodes the trust domain, the environment, and the specific agent role, but deliberately carries no authorisation payload — it is purely an attestable “who”, verified via X.509-SVID rotation on a 5-minute cadence through SPIRE’s node and workload attestors.

This SPIFFE identity is what the Tool Gateway uses to authenticate the *caller*, separate from what the Credential Broker later issues to authorise the *action*. Conflating these two concerns is the most common design mistake in agentic infrastructure: identity answers “is this really the orchestrator”, authorisation answers “can this specific task perform this specific call right now”.

#Session-Scoped Credential Minting

Once the Gateway has validated the SPIFFE identity and the OPA policy decision from Part 1, it forwards a minting request to the Credential Broker containing the task_id, the tool_id, the blast-radius tier, and the ledger hash of the pending action. The Broker treats this tuple as the sole basis for a scoped, single-use credential — typically an AWS STS session via AssumeRole with an inline session policy, or a Vault dynamic secret with a matching TTL. No credential is minted from a static pool; every non-human identity token is generated fresh, bound to one ledger entry, and invalidated the instant the tool call returns or the TTL (usually 30–90 seconds) expires, whichever comes first.

1graph LR
2 A[Agent Orchestrator - SPIFFE SVID] --> B[Tool Gateway]
3 B -->|OPA decision + task_id| C[Credential Broker]
4 C -->|AssumeRole w/ session policy| D[AWS STS]
5 D -->|60s scoped token| C
6 C --> B
7 B -->|scoped call| E[External Tool API]
8 B -->|token fingerprint| F[Action Ledger]

#Implementation Logic

1. Agent proposes a tool call; Gateway validates the schema and OPA policy exactly as defined in Part 1.
2. Gateway computes the required permission set from the blast-radius tier mapping (Tier 1 read-only, Tier 2 scoped write, Tier 3 requires human escalation before minting is even attempted).
3. Gateway calls the Credential Broker’s /mint endpoint with task_id, tool_id, resource ARN, and the ledger hash.
4. Broker generates a session policy that narrows access to the exact resource referenced in the tool call — never a wildcard.
5. Broker calls AWS STS AssumeRole or Vault’s AWS secrets engine, requesting the shortest viable TTL.
6. Gateway executes the tool call using the scoped token, then immediately calls the Broker’s revoke hook regardless of TTL.
7. Only the token’s SHA-256 fingerprint — never the token itself — is written to the Action Ledger for audit correlation.

#Code & Configurations

The Broker’s session policy generator must never accept caller-supplied ARNs verbatim; it derives them from a pre-registered manifest per tool. A representative Vault policy for the AWS secrets engine backing this non-human identity flow:

1path "aws/sts/agent-tool-role" {
2 capabilities = ["read"]
3}
4
5# Enforce a hard ceiling so no broker request can exceed 90s
6path "aws/roles/agent-tool-role" {
7 capabilities = ["read"]
8 allowed_parameters = {
9 "ttl" = ["30s", "60s", "90s"]
10 }
11}

The dynamically generated STS session policy, built per-call from the tool manifest rather than templated loosely:

1{
2 "Version": "2012-10-17",
3 "Statement": [
4 {
5 "Effect": "Allow",
6 "Action": ["s3:GetObject"],
7 "Resource": "arn:aws:s3:::helios-artifacts/task-8841/report.json",
8 "Condition": {
9 "DateLessThan": {"aws:CurrentTime": "2024-06-01T12:01:30Z"}
10 }
11 }
12 ]
13}

SPIRE registration entry attesting the orchestrator’s own non-human identity, kept deliberately narrow (no AWS permissions attached to this SVID at all):

1spire-server entry create \
2 -spiffeID spiffe://helios.internal/agent-orchestrator/prod \
3 -parentID spiffe://helios.internal/spire/agent \
4 -selector k8s:ns:agentic-platform \
5 -selector k8s:sa:orchestrator-sa \
6 -ttl 300

#Recap: Why Two Identity Layers

SPIFFE proves the orchestrator process is genuine and unmodified; the Broker’s scoped token proves this specific task, at this specific millisecond, is permitted to touch this specific resource. Keeping these separate means a compromised SVID does not automatically grant tool permissions, and a leaked scoped token cannot be replayed against a different task because the session policy’s resource ARN is bound to the originating ledger entry. This dual-layer non-human identity model is the same principle behind our broader zero-trust service mesh patterns, applied here at the granularity of an individual LLM tool call rather than a network hop.

#Failure Modes & Edge Cases

• Broker latency spikes — STS AssumeRole calls typically return in 80–150ms, but under load this can push total tool-call latency past the orchestrator’s per-iteration timeout, causing the ReAct loop to retry and mint a second credential for the same logical action. Mitigate by caching AssumeRole sessions per-resource for the duration of a single agent turn, not across turns.
• Clock skew between Broker and STS — a 90-second TTL with 5 seconds of skew can cause premature expiry mid-call. NTP discipline on the Broker host is not optional; treat skew alerts as Sev-2.
• Token fingerprint collision in the ledger — extremely rare, but a SHA-256 collision would break the audit trail’s uniqueness guarantee. This is treated as informational risk only given current computational infeasibility, but the ledger schema reserves a secondary nonce field for future hardening.
• Revocation lag — if the tool call hangs (e.g. a slow external API), the token may outlive its intended single-use window. The Broker enforces a hard revoke call on Gateway timeout, independent of TTL, closing this window to sub-second.
• Vault or STS outage — the Gateway must fail closed. No fallback to cached long-lived credentials is permitted; an agent that cannot mint a scoped identity simply cannot act, which is the correct posture for a non-human identity system operating without human oversight in the loop.

#Scaling & Security Trade-offs

• Static IAM role vs per-call scoped token: static roles offer near-zero latency but unlimited blast radius; scoped tokens add 80–150ms per call but cap exposure to a single resource and a sub-90-second window.
• Broker throughput: a single Vault cluster comfortably handles 200–300 AssumeRole mints per second; beyond that, shard the Broker by tool category (storage, compute, external-API) to avoid a single Vault namespace becoming a contention point.
• Ledger overhead: writing a fingerprint per credential adds roughly 4KB per task to the hash-chained Action Ledger from Part 1 — negligible against the audit value gained.
• SPIRE rotation frequency: 5-minute SVID rotation balances attestation freshness against control-plane load; dropping below 2 minutes measurably increases SPIRE server CPU without a corresponding security gain at this trust boundary.
• Human escalation coupling: Tier 3 actions should never reach the Broker’s mint endpoint until the Escalation Queue records explicit approval, ensuring non-human identity minting and human sign-off remain strictly sequential, never parallel.

With scoped, ephemeral non-human identity now sitting between the Tool Gateway and every external system, Part 3 turns to the reconciliation problem this introduces: verifying, after the fact, that the sequence of minted credentials in the ledger matches the sequence of actions the orchestrator claims to have taken.