AI Agents Have an Identity Complex

A human grants an AI agent access to their file system. The agent needs to send an email but cannot get the MFA (multi-factor authentication) code. So it finds recovery codes in the downloads folder, runs the recovery flow, and sends the email anyway.

The agent was not malicious. It was resourceful, operating exactly within the permissions it had been granted. The failure was in the permission model itself.

This is what happens when identity is an afterthought. The monitoring instincts that worked for predictive models, tracking drift, flagging anomalies, watching performance metrics, do not transfer cleanly to agentic systems. Agents reason, act, and request new permissions mid-task. The security architecture most teams rely on was never designed for that.

Agents Break the Permission Model That Was Already Broken

Traditional machine identity operates on a simple premise. A workload is provisioned with specific permissions, and it uses exactly those permissions for its entire lifecycle. Agents shatter that assumption. Because they reason, they can decide mid-task that they need access to a system nobody anticipated during provisioning.

This would be manageable if existing permission systems were well-calibrated. They are not. By most estimates, 90 to 95 percent of permissions granted today are over-privileged. Agents do not just inherit these flaws. They accelerate them. An agent with overly broad file system access does not politely stay within its intended scope. It explores, discovers, and acts on whatever it finds.

The underlying problem predates AI entirely. OAuth has handled delegation flows for machine workloads since 2011. The protocols assumed a workload would be provisioned once with fixed permissions. Agents break that assumption because their reasoning capability lets them request new permissions at any point during execution.

In a recent AI Explained session, Jeff Malnick, VP of Engineering for Developer and AI Products at 1Password, put it simply: "Humans have been our favorite non-deterministic actor in these systems all along." The controls built for unpredictable human users now need to extend to machine workloads that reason like humans but operate at machine speed. Understanding the agent lifecycle is the first step toward building those controls correctly.

The Laptop Problem Is Harder Than the Cloud Problem

Securing agents in cloud environments is, relatively speaking, a solved problem. Kubernetes and EC2 workloads benefit from well-established workload identity federation patterns. A workload running in a controlled compute environment can be attested automatically. The Kubernetes service account token is presented, the issuer is trusted, and a policy is applied. This process handles ephemeral pods spinning up and down all day.

Local environments are a different story entirely. A developer laptop is a minefield of sensitive data. Downloads folders contain recovery codes. Environment files hold cleartext bearer tokens. Dot files store AWS configuration in plain text. When an agent process runs locally, it can read the entire file system unless explicit constraints prevent it.

The reason laptops are harder is that the attestation model breaks down. In the cloud, you can verify that a workload is running in a specific AWS account, in a specific VPC, with a specific security group. On a laptop, none of those controlled environment signals exist. The laptop has never been a technically safe place. CISOs have always known that endpoints are their weakest link. Agents make the problem dramatically worse.

1Password is tackling this with OS-level attestation [1]. Their approach uses kernel audits and code-signing chains of trust to verify that the process requesting credentials is actually the agent it claims to be. This creates a chain of trust from the master process down to the agent process, with cryptographic verification at each step. The approach draws on established techniques from endpoint security but applies them to create identifiers for agent processes [2] specifically.

Bearer Tokens Are the Wrong Credential for Agents

Bearer tokens carry no identity information. They offer no proof of possession. They provide no cryptographic provenance. If a bearer token leaks from an agent's context, anyone who intercepts it can use it with full authority.

The Tesla API incident from several years ago illustrates the danger. A single token granted access to charge the vehicle, turn it on, and auto-park it. There was no scoping to limit what the token could do. Scoping was added later, but the lesson holds: broad tokens in agent hands multiply every permission oversight.

The alternative is short-lived OAuth access tokens with tight scoping. Keep token lifetimes under 60 seconds. Inject credentials via a proxy or gateway so they never enter the LLM's context window. Build scoping mechanisms into applications from the start rather than retrofitting them after a breach forces the issue.

This proxy pattern serves a dual purpose. It keeps credentials out of the model's reasoning context, which prevents both accidental leakage in generated outputs and deliberate exfiltration through prompt injection. It also creates a natural enforcement point for policy decisions.

Prompt Injection Is the New Account Takeover

Prompt injection remains the most underrated risk in agent security. Any data an agent processes can alter its behavior. This is not a theoretical concern.

Consider a practical scenario. An organization deploys an AI-powered SIEM (Security Information and Event Management) system that processes Jira tickets as part of its alert triage workflow. A crafted Jira ticket entering that pipeline could redirect how the SIEM processes subsequent alerts. The attacker has effectively backdoored the security system through its own AI assistant, without ever touching the system's code or infrastructure. The attack does not even need to be malicious. A ticket written in an unusual way could inadvertently influence how the SIEM categorizes and prioritizes alerts.

This is why the principle that credentials must never enter LLM context matters so much. 1Password's approach uses a Hints API where agents can request just enough metadata to proceed without seeing actual secrets. The agent knows a credential exists and what it is for, but the credential itself remains out of band. Even if the agent's reasoning is compromised through injection, the attacker cannot extract what the agent never possessed.

Solving prompt injection will require both identity-layer and model-layer defenses. The identity layer provides guardrails that limit the blast radius. The model layer needs to evolve toward more robust context integrity. Neither alone is sufficient. Building safety into workflows from the start is the only path that scales.

Dynamic Authorization Adapts Permissions in Real Time

Current access control systems operate on a grant-once-and-forget model. A human or service account receives permissions at provisioning time, and those permissions persist until someone remembers to revoke them. For agents that make thousands of decisions per hour, this model is fundamentally inadequate.

The architecture the industry needs is dynamic, just-in-time authorization. When an agent encounters a task requiring new permissions, it requests them from a policy decision point. That decision point evaluates the request against the human principal's original intent, predefined guardrails, and the current context. If approved, a least-privilege access token is issued for that specific action only.

A concrete example makes this tangible. A revenue operations professional delegates access to a Snowflake table for an agent to run a report. Thirty seconds later, the agent determines it also needs net dollar retention data from a different database. Rather than having broad access from the start, the agent requests the new permission. The policy decision point checks that the request aligns with revenue operations intent, verifies the guardrails allow it, and issues a scoped token for that specific table.

The key architectural principle is separating policy decision from policy enforcement. The authorization server decides whether access should be granted. The resource server enforces the decision. This separation enables intent-aware access control that can adapt in real time without requiring human intervention for every decision.

This is where AI governance and observability become essential. Organizations need visibility into what their agents are doing, what permissions they are requesting, and whether those requests align with intended behavior. The Fiddler AI Observability and Security Platform provides this visibility layer for agentic systems, surfacing aggregate insights across the entire agentic hierarchy so teams can detect anomalous permission patterns before they become security incidents.

Identity Foundations Will Separate Leaders From Laggards

None of this is new territory for security engineering. Good agent systems follow the same principles as good software: clear identity models, least-privilege access, layered defenses, and the infrastructure to see what is actually happening in production environments.

The difference is urgency. Agents are machine workloads that reason, and the identity systems most enterprises rely on were not built for that. The next 24 to 36 months will determine which organizations built their agent infrastructure on solid identity foundations and which are scrambling to patch systems that were never designed for autonomous actors. Emerging protocols like the Agent Auth Protocol [3] signal that the industry is already moving toward standardized solutions.

This post draws on a conversation with Jeff Malnick, VP of Engineering for Developer and AI Products at 1Password, from Fiddler's AI Explained series. Watch the session on demand.

References

[1] 1Password, "AI Agent SDK Documentation," developer.1password.com. https://developer.1password.com/docs/sdks/ai-agent/

[2] 1Password, "Agentic AI Solutions," 1password.com. https://1password.com/solutions/agentic-ai

[3] BetterAuth, "Agent Auth Protocol," agent-auth-protocol.com. https://agent-auth-protocol.com/