Your monitoring dashboards track model drift. Your validation protocols check performance metrics. Your governance frameworks document approval workflows. None of them were designed for the moment an AI agent decides, mid-task, that it needs access to a system you didn't provision.
That moment is happening now, and most teams are making the same five mistakes.
Why These Mistakes Keep Happening
Teams are applying identity and access controls designed for predictable workloads to systems that reason. Traditional machine identity assumes you provision permissions once and the workload uses exactly those permissions for its entire lifecycle. Agents disrupt that model because they can decide, based on their reasoning, that they need new access mid-execution.
This wouldn't be catastrophic if existing permission systems were well-calibrated. They aren't. By most estimates, 90 to 95 percent of permissions granted today are over-privileged. Agents don't just inherit these flaws, they accelerate them. An agent with overly broad file system access doesn't politely stay within its intended scope. It explores, discovers, and acts on whatever it finds.
Mistake 1: Treating Laptops Like Cloud Workloads
Why it happens: Cloud workload identity federation is a solved problem. Kubernetes service accounts, AWS IAM roles for pods, and workload identity patterns provide strong attestation. Teams assume the same patterns transfer to local environments.
The consequence: 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. Cloud attestation signals, specific VPC, security group, account ID, don't exist on endpoints.
The fix: Implement OS-level attestation for agent processes. 1Password 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 cryptographic chain from the master process down to the agent process. Without this, you're trusting that the agent is who it says it is based on nothing more than the process name.
Mistake 2: Putting Bearer Tokens in Agent Context
Why it happens: Bearer tokens are the default credential type for API access. They're convenient, widely supported, and easy to pass between systems. Teams provision them the same way they would for any other automated workload.
The consequence: Bearer tokens carry no identity information, no proof of possession, and no cryptographic provenance. If a bearer token leaks from an agent's context, through a log file, an error message, or prompt injection, anyone who intercepts it can use it with full authority. Worse, because the token sits in the agent's reasoning context, the agent itself can inadvertently expose it in generated outputs.
The fix: Use short-lived OAuth access tokens with tight scoping, and keep them out of the LLM's context window entirely. Inject credentials via a proxy or gateway. Keep token lifetimes under 60 seconds. The proxy pattern serves dual purposes: it prevents accidental leakage in generated outputs and creates a natural enforcement point for policy decisions. 1Password's Hints API demonstrates this approach, agents can request metadata about credentials without ever seeing the actual secrets.
Mistake 3: Ignoring Prompt Injection as an Access Control Bypass
Why it happens: Teams treat prompt injection as a content moderation problem, not a security problem. The focus goes to preventing offensive outputs, not preventing privilege escalation.
The consequence: Any data an agent processes can alter its behavior. Consider an AI-powered SIEM system that processes Jira tickets as part of alert triage. A crafted Jira ticket entering that pipeline could redirect how the SIEM processes subsequent alerts. The attacker has effectively backdoored the security system without touching code or infrastructure. The attack doesn't even need to be malicious, a ticket written in an unusual way could inadvertently influence alert categorization.
The fix: Implement identity-layer defenses that limit blast radius regardless of model behavior. Never put credentials in LLM context. Use structured interfaces where agents request actions through APIs rather than generating raw commands. Build observability that flags when an agent's permission requests deviate from baseline patterns. Prompt injection will remain a model-layer problem for years, but identity-layer controls can contain the damage today.
Mistake 4: Provisioning Permissions Once and Forgetting Them
Why it happens: Traditional access control operates on a grant-and-forget model. A human or service account receives permissions at provisioning time, and those permissions persist until someone remembers to revoke them. This works for predictable workloads that don't make autonomous decisions.
The consequence: An agent making thousands of decisions per hour with static, over-privileged permissions is a standing invitation for both accidental damage and deliberate abuse. When the agent discovers it needs access to a new system, it either fails (breaking the workflow) or uses overly broad permissions it already has (violating least privilege).
The fix: Implement 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 current context. If approved, a least-privilege access token is issued for that specific action only. The architectural principle is separating policy decision from policy enforcement, the authorization server decides, the resource server enforces.
Mistake 5: Lacking Visibility Into Agent Permission Patterns
Why it happens: Existing observability focuses on model performance metrics: latency, throughput, accuracy, drift. Teams assume that if the model is performing well, the agent is behaving correctly.
The consequence: You can't detect anomalous permission requests if you're not tracking them. An agent that suddenly requests access to financial data when it's been working in customer support for weeks is either encountering a legitimate edge case or experiencing a prompt injection attack. Without aggregate visibility across the agentic hierarchy, you won't know which until after the damage is done.
The fix: Deploy observability infrastructure that surfaces permission request patterns, not just model outputs. Track what agents are requesting, when they're requesting it, and whether those requests align with their stated purpose. Build alerting for deviations from baseline behavior. This isn't model monitoring, it's identity and access monitoring adapted for autonomous actors.
Prevention Checklist
Before you deploy your next agent:
- Implement OS-level attestation for agent processes running on endpoints
- Remove all bearer tokens from agent context; use short-lived scoped tokens via proxy
- Build structured APIs for agent actions; never let agents generate raw commands
- Deploy dynamic authorization that evaluates permission requests against intent and context
- Instrument observability for permission request patterns across your agent hierarchy
- Document the human principal's intent for each agent delegation
- Define guardrails that constrain agent behavior regardless of model output
- Test prompt injection scenarios that attempt to escalate privileges
- Establish a process for revoking agent permissions when the delegating human's session ends
The organizations that get this right in the next 24 months will have built agent infrastructure on solid identity foundations. The ones that don't will be retrofitting security controls onto systems that were never designed for autonomous actors. That retrofit is expensive, disruptive, and often incomplete.
Your agents are already requesting permissions you didn't anticipate. The question is whether you'll know about it before someone else does.
