What Changed
A significant governance gap exists: 59% of organizations using AI agents haven't adapted their Identity and Access Management (IAM) policies to include these systems, according to JumpCloud's survey. Meanwhile, 55% of organizations are deploying or testing agents capable of altering systems, permissions, records, or workflows.
This isn't theoretical. Your agents are active and may be operating outside your control framework.
The issue is that agents behave differently from traditional machine identities. They make non-deterministic decisions, operate at scale, and often act without human intervention. Forrester's Andras Cser describes them as "smarter, less deterministic APIs," meaning your existing API key management won't suffice.
Key Findings
Most organizations approve first, audit later. JumpCloud found that 46% of organizations allow high-risk actions to occur automatically, reviewing logs afterward. Another 29% allow such actions with limited or no review. Only 18% require prior human approval for high-risk agent actions.
This approach reverses the principle of least privilege. You're granting broad permissions upfront and relying on audit trails to catch problems after they've impacted production systems, customer data, or compliance scope.
Agents lack distinct identities. Most deployed agents share human credentials, use static API keys, or operate with long-lived bearer tokens. NIST researchers Bill Fisher and Ryan Galluzzo recommend treating agents as "first-class entities" with unique identifiers and credentials tied to the authorizing user or system.
Without distinct identities, you can't answer basic audit questions: Which agent accessed this database? Who authorized it? What permissions did it actually need?
Accountability chains don't exist. When an agent takes an unwanted action, someone must own the outcome. If your agent uses a shared service account or a developer's personal API key, you've broken the chain of custody. Cser's rule applies here: "There needs to be somebody at the end of the story."
Your agent inventory is incomplete. Discovery is essential for governance. If you don't know which agents are running, which models they use, or which humans authorized them, you can't assess risk or demonstrate control effectiveness during an audit.
What This Means for Your Team
If you're maintaining SOC 2 or ISO/IEC 27001 certification, agents fall within your existing control scope. SOC 2's CC6.1 (logical and physical access controls) and ISO/IEC 27001:2022 Annex A Control 5.15 (access control) include AI systems. Your auditor will ask how you're enforcing least privilege, reviewing access, and maintaining accountability for non-human identities.
The challenge increases when agents operate across multiple trust boundaries. If your procurement agent can modify supplier records, approve purchase orders, and update financial systems, it's violating segregation of duties that would fail a human access review. Automation doesn't eliminate the control requirement.
Consent fatigue also creates audit risk. NIST warns that excessive human-in-the-loop prompts condition users to approve requests without adequate review, undermining your approval controls. You'll need to determine which actions require human judgment and which can proceed under policy constraints.
Action Items by Priority
1. Inventory your agents now. Document every agent in your environment: the model or framework it uses, the systems it accesses, the human or team that authorized it, and the actions it's permitted to take. Treat this like a user access review under ISO/IEC 27001 Annex A Control 5.18. If you can't produce this inventory during your next audit, you're documenting a control gap.
2. Assign distinct identities and credentials. Stop using shared service accounts or human credentials for agent authentication. Implement short-lived, scoped credentials using OAuth 2.0, SPIFFE, or your existing IAM provider's machine identity capabilities. Each agent identity should map to an accountable owner, the person or system that authorized its deployment.
3. Evaluate access decisions across three contexts. Cser's "three identities, three contexts" model applies here: assess the human user's role and permissions, the agent's model and stated intent, and the target resource's sensitivity and policy requirements. Your access decision should consider all three. If your agent can bypass approval workflows that humans must follow, you're creating an audit exception without documented justification.
4. Build audit trails that explain decisions. Your logs must capture what agent acted, when it acted, which human authorized it, what action it took, which credentials it used, and why it chose that action. Reason codes matter. During an incident investigation or audit sampling, you need to reconstruct the decision path, not just the outcome.
5. Require prior approval for high-risk actions. If an agent can delete production data, modify access permissions, or approve financial transactions above a threshold, require human approval before execution. Yes, this reduces automation efficiency. It also prevents the scenario where you're explaining to your auditor why an agent deleted customer records and you only noticed three days later during log review.
6. Establish an approved agent registry. Define which agent types, models, and providers your organization permits. Require approval before teams deploy new agents, just as you'd require approval before granting administrative access to a new vendor. This registry becomes your population for periodic access reviews.
By addressing these action items, your team can integrate AI agents into your IAM framework effectively, maintaining security and accountability as these agents gain more autonomy and influence within your enterprise.
