Securing non-human identity in an agent-first stack

Your IAM was built for humans logging in twice a day. Your agents authenticate four thousand times an hour, spawn sub-agents, and pass tokens between tools you don't own. Here's the architecture we deploy for BFSI customers — and the three failure modes we keep finding in production.

Blackbead.ai

AI security research

Every IAM system in production today was designed around a single mental model: a person sits at a desk, signs in once or twice a day, and acts on behalf of themselves. That model is no longer load-bearing. The fastest-growing identity in your stack isn't human — it's the agent your data team stood up last quarter to autopopulate ledgers, the helper your CISO bought to triage tickets, and the dozen orchestrators your SaaS vendors quietly turned on.

We've spent the last eighteen months instrumenting agent identity at Indian BFSI customers. The pattern that keeps repeating: the agents work fine, the IAM team can't see them, and the audit trail breaks somewhere between the third and fourth tool hop. This post walks through the architecture we deploy and the three failure modes we always find first.

Why human IAM breaks for agents

Three properties make agent identity qualitatively different:

Authentication volume. A human authenticates ~5 times a day. A production agent authenticates 4,000–40,000 times an hour. Your SIEM cost model wasn't priced for that.
Delegation depth. A human delegates rarely and explicitly. An agent delegates to a sub-agent which delegates to a tool which delegates to a SaaS API — four hops before the original principal disappears from the trace.
Behavioural variance. A human has a daily rhythm. An agent's "normal" depends on the prompt that triggered it. The same agent, same key, same tool — but with a slightly different prompt — is a completely different actor from a risk standpoint.

Your existing controls — MFA, conditional access, anomaly detection tuned for humans — are blind to all three.

The architecture, in one diagram

The shape we deploy looks like this:

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Trigger     │──▶│ Orchestrator │──▶│ Tool / API   │
│ (human/cron) │    │    Agent     │    │   Action     │
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                    │
       ▼                   ▼                    ▼
┌────────────────────────────────────────────────────────┐
│   Workload Identity Broker  (short-lived, scoped)      │
│   ↳ binds: principal · prompt-hash · tool-allowlist    │
└────────────────────────────────────────────────────────┘
                              │
                              ▼
                  ┌───────────────────────┐
                  │  AgentCop sidecar     │
                  │  (PII / SPI / OWASP)  │
                  └───────────────────────┘

The non-obvious piece is the broker. Every agent invocation requests a fresh, scoped token from a workload identity broker. The token is bound to three things: the original human principal, a hash of the prompt that triggered this call, and an explicit allowlist of tools this agent is permitted to call for this prompt.

Why prompt-hash

Binding the token to the prompt means that if a prompt-injection payload mutates the agent's behaviour mid-execution, the token no longer matches and the broker rejects the next tool call. It's a small change that converts a runtime safety problem into an identity problem your existing PEP can already enforce.

Failure mode 1: shared service accounts

Every customer we've onboarded has the same problem in the same shape. The data team has one service account. The agents use it. The pipelines use it. The dashboard refreshes use it. When something goes wrong, the audit trail says svc-data-prod and nothing else.

The fix is unglamorous: one identity per agent class, broker-issued short-lived credentials, and a deny-by-default tool allowlist. The cost is the migration. We've never seen this skipped without it biting later.

Failure mode 2: lost provenance across hops

The agent calls a tool, which calls another agent, which calls an API. Three hops in, the original principal is gone. Your SOC sees activity from agent-finalizer and has no path back to the human who started the chain.

The fix is propagated provenance — every outbound call carries a signed header chain. Blackbead's AgentCop sidecar attaches it transparently; if you're building it yourself, the minimum viable version is a JWT with a chain claim each hop appends to.

Failure mode 3: drift between intent and action

The agent's prompt says "summarise the customer complaint." The agent decides, mid-execution, that summarising requires reading the full account history. The token allows it. Nothing in your IAM noticed the scope change because nothing is checking intent.

This is where behavioural baselining matters — not the human kind, but a per-prompt-class baseline. Same prompt class, same expected tool set, same data-volume envelope. Drift outside the envelope is the signal. We log it, AgentCop scores it, and the SOC gets a ticket with the original prompt attached.

What to do this quarter

Inventory your agents. Most customers think they have 3. They have 40.
Split shared service accounts by agent class. Pick the three most active first.
Wire a workload identity broker — Vault, AWS STS, or our own — in front of your most sensitive tools.
Turn on AgentCop (or any equivalent) for PII/SPI scanning at the egress side. The volume will surprise you.

None of this is novel as a primitive. The novelty is treating it as one stack, with one trust model, instead of four side projects.