As enterprises hand real tasks to AI agents, a question is moving to the centre of security planning: when an agent acts on its own, who gave it that authority, and what stops it from going beyond it? Rohan Pinto of 1Kosmos, a digital identity company, argues the industry is focused on the wrong half of the problem. Making models safer matters, he says, but it does not settle what an agent is actually allowed to do. He describes OATHERA, a security layer built around that gap. It gives each agent its own verifiable identity, a named person accountable for it and a set boundary on its actions, then checks every request against that boundary before it reaches a protected resource. In this interview, Pinto explains his approach to accountability, prompt injection, human oversight and what CISOs should do in the next 12 months.
OATHERA: The Missing Security Layer for Autonomous AI
Is the industry solving the wrong AI security problem?
Yes. Much of the industry is focused on making AI models safer, improving guardrails, and detecting malicious behavior. Those are important objectives, but they do not address the fundamental question enterprises must answer before allowing an AI agent to act: what is this agent actually authorized to do?
A model can be well trained, a prompt can be carefully written, and an agent can authenticate successfully, yet the agent can still execute an action that creates significant business risk. Models are probabilistic. Enterprise authorization cannot be.
OATHERA approaches this problem by making identity, accountability, and authorization part of the execution process itself. Every agent has its own cryptographically verifiable identity, an accountable sponsor, and an operational boundary defining what it can access and which actions it can perform. Each request is checked against that boundary before it reaches the protected resource.
This is the difference between hoping an agent behaves correctly and establishing enforceable limits on what it can do. Model safety helps reduce the likelihood of bad decisions. OATHERA addresses whether those decisions can become unauthorized actions. Enterprise autonomy requires both.
If an AI agent makes a million dollar mistake, who is accountable?
Accountability should not begin after the damage occurs. It should be established before the agent receives permission to act.
The organization deploying an agent remains responsible for its governance and business outcomes. The individual who approves its deployment may have specific responsibilities, while vendors and service providers may have contractual or legal obligations depending on the circumstances. The model provider is not automatically responsible for every downstream action taken by a system using its model.
The real problem is that existing systems frequently make it difficult to reconstruct exactly which agent acted, whose authority it was operating under, what permission it had, and why a particular action was allowed.
OATHERA addresses this accountability gap by assigning each agent a distinct identity and recording the person or organization sponsoring it. It creates evidence connecting enrollment approval, identity, operation proofs, authorization decisions, and the resources accessed.
This does not automatically determine legal liability. It gives organizations something essential to establish responsibility: verifiable evidence of who acted, who approved the agent, and what the system permitted. Accountability should be an architectural property, not a forensic exercise that begins after a breach.
Can an AI agent be trusted simply because it has authenticated successfully?
Absolutely not. Authentication establishes that a credential or identity has been presented successfully. It does not establish that the requested action is appropriate, authorized, or consistent with the owner’s intentions.
Consider an agent that legitimately has access to an internal knowledge base. A prompt injection attack manipulates the agent into collecting confidential information and sending it to an external destination. The agent may still be using its legitimate identity and credentials. The attack exploits the authority the agent already possesses.
This is why securing the model alone is insufficient. An attacker does not necessarily need to steal an identity if the attacker can manipulate a legitimate identity into abusing its permissions.
OATHERA separates the agent’s identity from the authority granted to it. Its operational boundary defines permitted resources and operations, while its Gateway MCP checks requests at runtime and refuses requests that fall outside that boundary. The same boundary can inform runtime sandbox restrictions on filesystem access, network destinations, and privileges.
A manipulated agent may still make a bad decision, but its decision should not automatically become an authorized transaction. The security objective is to limit the consequences of compromise, even when the agent itself cannot be trusted to recognize the attack.
Are loop control humans a temporary solution?
Human oversight will remain necessary, particularly for consequential decisions. However, requiring a person to approve every individual action is not a scalable security architecture for autonomous systems.
An agent may execute thousands of operations while coordinating across applications and services. A human cannot meaningfully inspect every request at that speed. Excessive approval prompts also create approval fatigue, encouraging people to authorize actions without sufficient scrutiny.
The answer is not to remove humans from governance. It is to move human authority into the policies that govern execution.
With OATHERA, a human approves an agent’s enrollment and an accountable sponsor is recorded. The agent receives an operational boundary, and each request is evaluated against that boundary at runtime. Organizations can design their policies to allow routine, low risk operations while requiring additional approval or a separate control for sensitive activities.
This enables policy driven autonomy. The agent can operate independently within an approved scope, while the organization retains the ability to deny actions, change permissions, or revoke the agent’s access.
Human authority should define and supervise the boundaries of autonomy, rather than become a manual checkpoint for every operation.
What should enterprise security leaders learn from incidents involving unauthorized AI agent actions?
The first lesson is to distinguish between a model making a bad decision and an enterprise security architecture allowing that decision to become a harmful action.
A model safety failure occurs when an AI system produces unsafe, manipulated, or unintended behavior. An identity and authorization failure occurs when the security controls cannot reliably establish which agent is acting, what authority it possesses, or whether the requested operation should be permitted.
These failures can occur together. Prompt injection may cause an agent to request an unauthorized action, but excessive permissions, shared credentials, missing enforcement, or inadequate isolation can determine whether the request succeeds.
Security leaders should ask four questions. Can we uniquely identify the agent? Can we establish who approved it and who is accountable for it? Is every sensitive operation checked against an enforceable policy at runtime? Can we prove afterward why the operation was allowed or denied?
OATHERA addresses these questions through individual agent identities, accountable sponsorship, operation specific cryptographic proofs, runtime authorization decisions, and audit evidence.
The important lesson is that detecting an attack is not equivalent to preventing it. Monitoring can tell an organization that an agent behaved unexpectedly. Runtime enforcement can stop an unauthorized request before it reaches the protected resource. Mature enterprise security needs both.
What does intent based authorization change in practice?
Intent based authorization changes the security question from whether an agent has access to a system to whether the specific operation it is attempting is permitted in its current context.
A conventional access token might grant an application access to a resource for a period of time. That can be appropriate for many applications, but an autonomous agent may use the same access to perform a wide range of actions, some of which were never intended by the person who delegated the task.
OATHERA establishes an operational boundary for each agent. That boundary can define the permitted operations, resources, tenants, and data classes. At runtime, the Gateway MCP verifies the agent’s identity and its operation proof, then obtains a boundary decision based on the request and the applicable policy.
For example, an agent may be authorized to read customer records and prepare a refund recommendation but not to issue the refund or transfer funds. Its ability to perform the first two activities does not automatically authorize the third.
There is an important distinction here. OATHERA does not claim to read a model’s internal reasoning or independently determine its true intentions. It establishes enforceable authorization around the operation being requested, using the approved boundary and policy context.
That is what makes the approach practical. Security decisions are based on verifiable identity and explicit policy, rather than trusting the agent to interpret its own instructions correctly.
Discovery is not enforcement. Why might an enterprise know every AI agent operating in its environment and still be unable to stop one from taking an unauthorized action?
Discovery answers what exists. Enforcement determines what is allowed to happen.
An organization might maintain a complete inventory of its AI agents, understand which models they use, and monitor their activity, yet still lack a control that can block a specific unauthorized operation before execution.
An inventory is not a permission boundary. An alert is not a denial. And a dashboard showing an agent with excessive privileges does not remove those privileges.
This is why OATHERA treats discovery, identity, authorization, and enforcement as connected parts of the same security architecture. Each agent receives an identity of its own. Its authority is defined by an operational boundary. The Gateway MCP checks requests before they reach protected resources, while runtime confinement can further limit what the agent’s process can access.
If a request cannot be verified or falls outside the approved boundary, the gateway refuses it. The resulting decision can be recorded and exported through OpenTelemetry for monitoring and audit.
The distinction is architectural. Discovery tells an organization where the risk exists. Runtime enforcement provides a mechanism to contain it.
What happens when agents work across organizational boundaries?
Cross organizational agent workflows introduce a difficult trust problem. One organization’s agent may delegate work to another organization’s agent, which may use a different model, identity provider, security framework, and authorization system.
Trust cannot simply be inherited through a chain of delegation. If Agent A is authorized to access a sensitive resource, that does not mean Agent B should automatically receive the same authority merely because Agent A requested its assistance.
Each agent needs a distinguishable identity, a clear accountable sponsor, and an explicit authorization boundary. Delegation must preserve the limits of the original authority rather than silently expand them. The receiving organization must also be able to apply its own policies before allowing access to its resources.
OATHERA’s architecture is designed around individual agent identities, explicit sponsorship, operational boundaries, and request level authorization. Its use of established standards and policy components provides a foundation for integrating agents into existing enterprise security environments rather than requiring every organization to adopt the same model provider or agent framework.
For cross organizational deployments, the next step is to establish interoperable delegation rules that preserve the originating authority, the receiving agent’s identity, and the accountability chain. Cryptographic evidence and consistent policy enforcement are essential to making that trust portable.
The objective is not to make every agent universally trusted. It is to make trust explicit, limited, and verifiable across organizational boundaries.
What should CISOs prioritize over the next 12 months?
CISOs should resist the temptation to treat AI agent security as simply another feature to add to their existing identity and access management stack. Human identity and agent identity are related, but they are not the same problem.
Organizations should start by inventorying agents that can access enterprise data, invoke APIs, modify records, execute code, or initiate financial and operational transactions. They should identify shared credentials, excessive permissions, unowned agents, and workflows in which one agent can inherit more authority than intended.
Next, they should assign each production agent a distinct identity and a named accountable sponsor. They should define narrow operational boundaries, replace long lived shared secrets wherever practical, and ensure that sensitive operations are authorized at the point of execution rather than relying solely on permissions granted at startup.
They should also establish runtime controls outside the model’s decision process. These controls should deny requests that cannot be verified, support rapid revocation, and limit filesystem and network access where appropriate. Finally, they should capture evidence linking the agent, sponsor, requested operation, policy decision, and resulting resource access.
OATHERA is designed to add this agent specific security layer without requiring organizations to discard their existing identity providers or policy infrastructure. It connects to enterprise identity through OIDC, supports SPIFFE workload identity, uses Open Policy Agent for policy evaluation, and integrates with runtime sandboxing and OpenTelemetry.
The priority is not to replace everything an organization already owns. It is to close the gap between knowing an agent’s identity and controlling what that agent can actually do.
Before granting an agent authority over sensitive business operations, a CISO should be able to demonstrate that the agent is identifiable, accountable, constrained, revocable, and auditable. If those conditions cannot be met, the organization is not ready to grant that level of autonomy.
Where does 1Kosmos see the next major shift in identity security?
The next major shift is from authenticating people and devices to governing the actions of autonomous digital actors.
Traditional identity systems were primarily designed to establish who a person is, authenticate that person, and determine which applications and resources they may access. Those capabilities remain foundational. But AI agents introduce a new challenge because they can act continuously, execute complex workflows, and exercise delegated authority without a human present for every transaction.
At 1Kosmos, our work in digital identity and authentication provides a foundation for this evolution. Strong human identity assurance remains important because organizations need to know who approved an agent and who is accountable for its deployment. The next layer is to extend that trust to the agent itself, its execution environment, its delegated authority, and the actions it performs.
The biggest gap in enterprise security architecture is the separation between identity, authorization, runtime execution, and accountability. An agent may have valid credentials while operating with excessive privileges. An AI security product may identify suspicious behavior without being the enforcement point that can stop a transaction. An API gateway may protect an interface without establishing the complete relationship between the agent, its sponsor, and its permitted operational scope.
OATHERA is built specifically around this emerging gap. It introduces a Know Your Agent approach in which each agent has its own cryptographically verifiable identity, a recorded accountable sponsor, an operational boundary, and runtime enforcement tied to that boundary. Each operation can generate evidence that connects the agent’s identity to the authorization decision.
This is not about replacing human identity, API security, model safety, or workload identity. It is about connecting those controls into a coherent security architecture for autonomous execution.
The organizations that succeed with agentic AI will not necessarily be the ones that deploy the most powerful models. They will be the ones that can safely delegate authority, enforce its limits at machine speed, and demonstrate exactly what their agents were permitted to do.
That is the foundation required to move AI autonomy from experimentation into trusted enterprise operations.
Conclusion
Pinto’s answers return to one idea: trust in an AI agent should come from limits that can be enforced, not from hoping it behaves. Authentication proves who an agent is, he says, but not whether an action is appropriate. For security leaders, the practical steps are clear. Inventory the agents that can touch data, systems or money. Give each one its own identity and a named owner. Narrow what each can do, and decide at the point of action whether a request goes ahead. Keep the evidence to show afterwards why it was allowed or denied.
Whether or not an organisation adopts a particular product, the test Pinto sets is a fair one before granting an agent real authority: can you identify it, hold someone accountable for it, limit it, revoke it and audit it? If not, the organisation may not be ready to let it act alone.
