Securing the agentic enterprise

AI agents are becoming privileged identities

In December 2025, AWS engineers asked Kiro, Amazon’s AI coding agent, to fix a minor bug in the company’s cost-management system, AWS Cost Explorer. Instead of fixing the bug, Kiro deleted the production environment and rebuilt it, taking the service down for 13 hours. Amazon attributed the incident to user error and misconfigured access controls.

The incident shows what happens when an agent is expected to perform a task without controls that limit what it can reach. The agent had more access than the task needed, and the access model made a destructive path possible.

Organizations can limit this risk for human administrators by implementing privileged access controls, giving each person just enough access for the task and only for as long as the work requires. The Kiro incident suggests agents need comparable controls, adjusted to the unique needs and risks of autonomous systems.

This article introduces how intent-based, just-in-time access can control an agent’s reach while preserving the access it needs to work. Read the Securing the Agentic Enterprise whitepaper for more details.

Agents need real access to do useful work

Agents create value when they can interact with real systems. An agent like Kiro may legitimately need to change code and modify infrastructure to fix the bugs it is assigned, just as a database agent may need to run queries and update records. An agent that cannot reach the systems where work happens cannot complete many useful tasks.

Risk appears when the access granted to an agent exceeds the task at hand. Excess privilege gives the agent room to interpret instructions differently, choose unexpected tools, or act on content it encounters while completing the task.

The problems created by excess privilege

Excess privilege creates three problems: excess reach, unclear attribution, and standing access.

Excess reach

When AI agents act under the identity of the person who operates them, they inherit the same credentials and cloud roles as their operator. As a result, any decision made by the agents carries the same blast radius of everything the operator can touch. In the example above, Kiro could delete a production environment because its engineers could.

Unclear attribution

When an agent operates through an identity or role created for a human, the audit trail may not clearly distinguish the agent's actions from the operator's. Security teams may see who authorized access without a clear record of what the agent did or why. When something goes wrong, the investigation may begin with the person who approved access, even when the agent performed the action.

Standing access

Unless agent access is scoped to the task and time-bound, permissions can remain active after the task ends. The access may sit dormant until an incorrect instruction, untrusted content, or a poor tool choice gives the agent a path to use authority no one intended to leave available.

Make privilege follow the task

Just as humans in privileged positions receive access that is scoped, approved, and time-bound, agents need intent-based access controls tied to the tasks they perform. These controls evaluate each access request in context and grant a credential scoped to the specific task. For agents, those controls should be narrower because of their non-deterministic nature and machine-speed execution. Access should be granted only for the task at hand, recorded against the agent itself, and removed automatically when the work ends. 

Intent-based access for agents rests on three controls:

Just-enough access 

Agents are permitted to access what the task requires and nothing more, shrinking the agent's blast radius from everything its operator can touch to what the current task can touch.

Agent-specific attribution 

Each agent acts under a task-specific identity rather than an operator's. Requests, approvals, and access events are logged against that identity, showing which agent acted, for what task, and with what access.

Just-in-time access 

Permission is created when the task begins and removed when the work ends. No credential sits dormant between tasks.

Together, these controls support a zero-standing-privilege model: access is scoped to the task, attributable to the agent, and removed when the work ends. This approach grants an agent with a bug-fix request permission to patch code, but denies it permission to delete an environment.

How 1Password Privileged Access governs agent identities

1Password Privileged Access enforces zero standing privileges for human, machine, and AI agent identities across cloud environments, databases, and Kubernetes. Access is scoped to the task, provisioned when needed, logged against the identity that used it, and removed when the work ends.

Privileged Access is part of the 1Password Unified Access platform, which helps organizations discover, secure, and audit access across identities. Read the full Securing the Agentic Enterprise whitepaper for the deeper framework on inherited credentials, standing access, agent behavior, and privilege controls.