The Identity Chain: Why Agents Break the Perimeter

What traditional controls can prove, and what they cannot

What they miss is the execution chain.

User prompt: “Give me team performance insights”
  ↓
Agent reasoning: [calls Workday API and retrieves 500 employee records]
  ↓
Agent reasoning: [queries salary database and accesses compensation data]
  ↓
Agent reasoning: [joins with performance reviews and combines sensitive datasets]
  ↓
Agent response: “Here’s the summary”

From an identity perspective, every step was authorized.

Authorization is not the same as appropriateness.

From a runtime perspective, the agent accessed more data than necessary and combined sensitive information in ways that violate governance policies.

A real example: the Glean incident

A CTO at a public company told me their workplace assistant had an HRIS integration with the permissions needed to answer org and people questions.

A user asked an innocuous question about their team.

The assistant pulled compensation fields too broadly and exposed salary information to the requester. The permissions were valid. The access was authorized. But the behavior violated governance expectations.

They only discovered this when someone noticed the exposed data. That is the governance gap: you only learn after exposure.

There was no runtime visibility into what the assistant was actually doing with HRIS permissions. No alert that sensitive salary fields were accessed at scale. No policy enforcement tied to the data flow between the HRIS connector and the user session.

The identity chain problem in practice

When people say “the agent’s identity,” they usually mean one thing. In real systems, multiple identities show up across a single user request.

This is where context gets lost. IAM logs show a legitimate service principal, but the initiating user, original prompt, and intermediate agent steps are not reliably attached.

Even with allowlisted tools, prompt injection and indirect prompt contamination can drive confused deputy behavior. The tool server faithfully executes a harmful request under a valid identity, and authorization logs stay clean.

Why PAM and JIT fail for agents

PAM and JIT were built for predictable workflows. Approve access, perform task, revoke access.

Agents are nondeterministic. The same prompt can trigger different execution paths each time:

Run 1: queries HRIS, accesses 50 records
Run 2: same prompt, accesses 500 records including compensation fields
Run 3: same prompt, joins HRIS plus performance data and exports results

You cannot precompute least privilege for a workflow that changes every run.

Either way, you have either added friction or increased blast radius.

What you actually need: runtime visibility

Security for agents is not “more identity controls.” It is visibility into what agents do with the permissions you grant them.

For every action in the execution chain, capture:

Then enforce policies based on behavior:

These policies cannot be enforced at the identity layer. They require runtime visibility.

Takeaway

Identity matters in the agentic era, but “identity is the perimeter” is incomplete.
Agents need broad permissions to be useful. The risk is not unauthorized access. It is authorized access used in unauthorized ways.

The organizations getting this right are not adding more identity controls. They are building runtime visibility into agent behavior and data access patterns, so they can answer:

This requires runtime telemetry, data access monitoring, and contextual policy enforcement. The framing needs to shift from “lock down identities” to “see and govern what agents actually do.”