Agentic AI
,
Identity & Access Management
,
Identity Security
Autonomous Systems Need Distinct Identities, Limited Access and Human Owners
More enterprises are empowering artificial intelligence agents to act on behalf of the business, but the identity and governance systems needed to control them are evolving more slowly.
See Also: Securing AI at Scale, Identity as the Foundation for Trust
A new survey from cloud-based directory and IT management platform vendor JumpCloud found that 55% of organizations use or test agents capable of changing systems, permissions, records or workflows. But among the respondents whose organizations are using agents, 59% have not fully extended their human identity and access management policies to these non-human users.
Forrester Vice President and Principal Analyst Andras Cser described AI agents as smarter, less deterministic APIs, and said that the combination of scale and autonomy at the enterprise level creates an amplifying effect. Enterprises can have significantly more agent identities than human users, and each may operate with more independence than traditional machines.
But the challenge for CIOs and CISOs is figuring out how to bring agents into their existing enterprise identity frameworks before they gain more autonomy and take actions the business doesn’t want.
“The first and foremost important thing is to treat AI agents in the framework of existing identity and access management,” Cser said. Agents are a new identity type, he said, but they shouldn’t be managed through a framework completely separate from business users, administrators and existing machine identities.
The process starts with discovery. Enterprises need an inventory of the agents operating in their environments, an approved pool of agent types and providers, and a process for reviewing the agent roster as capabilities and risks evolve.
Each agent should also have its own identity and credentials. Those credentials should identify the agent while preserving its relationship to the human or system that authorized it.
“There needs to be somebody at the end of the story,” Cser said. “You cannot just say, ‘We launched a bunch of agents from a script, and it did whatever it did.'”
Enterprises need “personal, employee or workforce or customer-level accountability for agent actions,” he said.
The National Institute of Standards and Technology reached a similar conclusion in a recent blog post. Agents should be treated as “first-class entities” with unique identifiers, credentials and entitlements bound to the user or system operating them, NIST researchers Bill Fisher and Ryan Galluzzo wrote.
NIST warned against letting agents use shared human credentials, static API keys or long-lived bearer tokens. Instead, existing mechanisms including OAuth 2.0 and the Secure Production Identity Framework for Everyone, or SPIFFE, can provide a starting point for issuing short-lived and tightly scoped credentials.
Identifying an agent is only the beginning. Organizations must also determine if agents are allowed to take specific actions at specific times.
Cser said organizations need to evaluate “three identities and three contexts” – those of the human user, the agent and the resource on which the agent wants to act.
With a procurement agent, for example, considerations include the employee’s role, location and budget, as well as the agent’s model, permissions and stated intent. The supplier and transaction also must comply with company policy.
Using those signals, the system can determine whether a transaction should proceed, be stopped or receive what Cser called a “yellow” decision, allowing it to proceed only under specified conditions.
JumpCloud found that 46% of agent-using organizations allow high-risk actions to occur automatically and review the logs afterward. Another 29% allow such actions with limited or no review, while only 18% require prior human approval.
Prior approval is not appropriate for every action, however. NIST warned that excessive human-in-the-loop requests can create consent fatigue, conditioning users to approve prompts without adequately reviewing them.
When an agent acts, the organization must be able to reconstruct why it made the choices it made.
“Audit trails should always include what agent, what runtime,” Cser said, along with the delegating human, timestamps, actions, credentials, resource identifiers and reason codes explaining why the agent chose one course over another.
That evidence will be essential when security teams, auditors, regulators or customers ask not only what happened, but why the system permitted it.
CIOs should also be skeptical of vendors claiming to offer a comprehensive control plane for agents. The market remains “the wild, wild west,” Cser said. He said CIOs should demand demonstrations of generally available products against the organization’s actual requirements.
“PowerPoint slides are easy to create,” he said.
For CIOs looking to wrangle agents already deployed in their environment, Cser said they should start with discovery, then establish an approved registry, assign each agent a distinct identity and accountable owner, and then connect access decisions to the surrounding business context.
Organizations should only use an agent if it creates enough business value to justify the cost of governing it.
“Not everything requires an AI agent,” he said.
Click Here For The Original Source.
