AI agents can act at machine speed, but before they go speeding along on a successful mission or to wreak unintentional havoc, enterprises must first stop them at the gate for an identity check. Organizations must ensure they know which agent is making a request.
To that end, SPIFFE — the Secure Production Identity Framework for Everyone — is an open standard that assigns verifiable cryptographic identities to software workloads, including AI agents. Still, proving an agent's identity isn't the same as determining what it should be allowed to access, decide or change. As enterprises deploy more autonomous agents, that distinction exposes a critical security and governance gap: If SPIFFE identifies the agent, what controls the agents' actions?
"SPIFFE confirms the presence of agents and prevents spoofing. That's it," said Karthik Karunanithi, solution architect at IBM. "Therefore, to stop an agent from doing damage when they misunderstand a request, an authorization layer must be layered on top of SPIFFE."
Related:AI panic is giving CIOs a new trust problem
Agent frameworks and gate guards
To better understand what SPIFFE can and cannot do, it's important to differentiate SPIFFE from SPIRE — SPIFFE Runtime Environment. SPIFFE defines open standards for workload identity, while SPIRE is a production-ready implementation of SPIFFE APIs. SPIRE performs node and workload attestation to securely issue SPIFFE Verifiable Identity Documents (SVIDs). SVIDs, which are cryptographically verifiable credentials that workloads use to prove their identities, carry a workload's SPIFFE ID and are available in X.509 certificate and JWT formats.
In a SPIRE deployment, the SPIRE Server manages identity issuance for its configured SPIFFE trust domain. It stores workload registration entries and signing material, authenticates SPIRE Agents through node attestation, and issues workload SVIDs through those agents. It also maintains trust-bundle information used to validate SVIDs and can participate in federation between separately configured trust domains.
While SPIFFE and SPIRE establish and verify workload identity, a separate authorization and policy-enforcement layer is required to determine what that authenticated workload is permitted to access or do.
What can control agents after they are identified?
For years, the specter of rogue AI belonged largely to science fiction, scratching faintly at the back of the public mind. Then came a rapid succession of reports of AI-based cybersecurity breaches involving OpenAI models and Hugging Face, Claude and Gemini. Still, Ben Bernstein, manager of cybersecurity advisors at global cybersecurity company Huntress Labs, explained that rising fear around rogue AI agents is overblown.
Related:The week of Sept. 7 - 11: What happened, what matters, what's next
"The doomsday scenarios are overhyped because we already have a 20-year playbook for this. A rogue AI agent is functionally no different than a compromised service account or a runaway script," Bernstein said.
Since AI is just another automation tool, albeit a highly sophisticated one, Bernstein advocates that organizations use basic role-based access control (RBAC), continuous monitoring and testing. "Treat an AI agent like any other new or untrusted application. Sandbox it, red team it early and often, verify its actions, and never give it production write access on day one," Bernstein said.
While that may be a good starting point, he agreed that it certainly isn't the end in setting agent controls. Setting baseline permissions before considering a given task is the next step in layering agent controls.
On-behalf-of (OBO) AI agents operating for a human or parent agent shouldn't have more permissions than their creators, explained Amihai Neiderman, co-founder and CTO at identity security company NewCore. In addition, autonomous agents should be restricted by guardrails established by the IT team or CISO, he said. From that basic foundation, Neiderman recommends the following:
Related:The week of Aug. 31-Sept. 4: What happened, what matters, what's next
Task-based limits: Give an agent only the access required for its current task, such as read-only access to one budget document rather than access to all payroll or payment systems.
Sub-agent permissions: Give sub-agents narrower permissions than their parent agent.
Intent checking: Block actions that do not match the assigned task, such as deleting files when the user asked only for a draft.
Context and state: Restrict an agent's capabilities after it encounters sensitive data, including blocking it from making external calls, sending emails and publishing sensitive data online.
Time and environment rules: Limit when an agent can perform sensitive operations and cap its queries or tool calls per session.
Human sign-off:Require approval before an agent moves money, deletes records or sends messages to large groups.
Prompts instructing an agent's work cannot replace any of these permission steps.
"Never delete data" in a system prompt is a suggestion, not a control, said Will Barker, cybersecurity advisor at Huntress. The Open Worldwide Application Security Project Foundation advises organizations to implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.
Barker also recommends an Open Policy Agent or similar for policy "but enforced at the gateway/API somewhere the agent can't route around." Lastly, he advocates the use of a kill switch that stops the agent's tools, cancels pending tasks and cuts off its access to connected systems while preserving a complete record of its actions. "Revoking credential renewal alone doesn't help if a live session survives," Barker said.
But what about the flip side: routine and repetitive agent tasks where few unwanted surprises are likely to pop up?
Jayakumar Ramalingam, staff software engineer and cloud architect at SiriusXM, recommends establishing guardrails for agents based on the possible damage they could cause and how difficult the action is to undo. "A complicated read-only query may be harmless. A basic API call may not be, especially if it changes customer data, moves money or affects production," he explained. An agent can handle low-impact actions that are easy to reverse, but "if recovery would require restoring data, reconciling transactions or contacting customers, a person should make the decision."
The authorization decision itself is just the starting point. Brian Trzupek, senior vice president of product management at DigiCert, advises enterprises to use continuous monitoring and keep records of agent actions. He added that organizations should ensure that they can suspend agents or revoke their identity and permissions immediately if needed.
Mopping up after an agent's misfire
Ultimately, agents act as directed or calculate actions based on insufficient or missing information; if they misfire, it's due to human error, not malicious intent.
That's not to say agents can't wreak havoc. Even with guardrails in place, an "agent might get tricked by prompt injection, run into an edge case , or misinterpret instructions if preventative agent controls fail, Neiderman said.
He recommended five steps for minimizing fallout:
Cap the blast radius: Grant least-privilege access through narrowly scoped, short-lived tokens that minimize exposure if an agent goes off course.
Kill the entire session: After an unauthorized action, terminate the run and revoke its tokens rather than letting the agent try another approach.
Treat wrong-tool calls as warnings: Regard an unexpected request for administrative or network tools as a security signal, not an innocent error.
Watch for behavioral drift: Track the agent's actions across steps and intervene when they begin moving away from the assigned goal.
Preserve human oversight: Maintain a complete audit trail and keep a human able to monitor, interrupt and stop the agent.
Finish the mop-up with an incident report detailing what went wrong and how to avoid a similar agent-based issue moving forward.