The next layer of AI security

Identity establishes trust. The next problem is how that trust is used.

In June 2025, Microsoft patched EchoLeak (CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot that allowed an attacker to exfiltrate sensitive enterprise data, including API keys, confidential documents, and internal conversation snippets, without human intervention.

The attack was deceptively simple. An attacker sent a normal-looking email with hidden instructions embedded in it. A human would not notice them, but the model could interpret them. The email remained dormant until Copilot later pulled it into context for another task. At that point, the instructions triggered, and the agent used the victim’s existing permissions to retrieve and disclose sensitive information.

The specific vulnerability matters, but the broader lesson matters more. A system can authenticate correctly, authorize correctly, and still produce the wrong outcome.

Microsoft patched EchoLeak before it was publicly disclosed. Since then, researchers have identified similar patterns across AI-assisted workflows, including additional Copilot-related vulnerabilities in 2026. These are not isolated issues. They point to a broader, repeatable pattern.

When AI systems process untrusted content and act with user-level permissions, prompt injection and unintended data access become systemic risks rather than edge cases. This is not a failure of authentication or authorization. It is what happens after both succeed. Systems are behaving exactly as designed, and still producing the wrong outcomes.

Prompt injection breaks the execution model

Prompt injection isn’t just a model issue. It’s a signal that something is breaking between how systems reason and how they act.

The industry sees the same thing. OWASP Top 10 for LLM applications ranks prompt injection as a primary attack vector, and research from OpenAI and others shows that models cannot reliably distinguish between legitimate instructions and malicious ones embedded in external content. Robustness to these attacks remains an open problem.

That means even when an agent has the right identity and permissions, it can still be pushed into using them incorrectly.

In our AI Agent Security Benchmark, we evaluated how agents behave across common workflows. What emerged consistently was not a failure of login or access control in the traditional sense. Even with valid credentials and permissions, agents routinely acted outside their intended scope, accessing sensitive data, misusing tools, or following manipulated instructions.

In one case, models correctly identified a phishing page but still opened it, retrieved credentials, and entered them. The issue wasn’t whether access was allowed; it was how that access was used. This is the access trust gap.

Today: Identity and authorization were built for a different world

Traditional enterprise security is built around two basic questions: who is this, and what are they allowed to access?

Authentication answers the first, and authorization answers the second. That model works when a few assumptions hold: a human is initiating the action, their intent is relatively clear, and everything happens within a defined session.

Agent workflows don’t fit that model: a single agent can move across multiple systems, use different credentials, and chain together actions in ways that aren’t always visible to the person who started the task. Intent is no longer fixed at the beginning of the session. It can shift during execution based on how the agent interprets the task, what it encounters, and what untrusted inputs get pulled into the workflow.

Identity still matters in this new world. You need to know what the agent is and who it’s acting for. Systems like OAuth and SAML provide that foundation. But identity answers a question that was asked before anything actually happens. It doesn’t tell you whether what’s happening now still makes sense.

Authorization has the same limitation. It checks scopes, roles, and whether access is valid. But that only tells you the agent can access something. It doesn’t tell you whether this specific action is appropriate.

Pulling model weights into an unmonitored environment, pushing code to a production branch at 2 AM, exporting data to an unknown endpoint. All of these actions can be allowed and still be wrong.

This introduces a new control boundary. It’s not just about who has access or what they’re allowed to do. It’s about how that access is actually used when something happens.

The gap between what’s allowed and what should happen in the moment is exactly what prompt injection exploits. Identity alone doesn’t close that gap.

The future: Dynamic authority and continuous enforcement

Instead of making a one-time access decision and assuming it holds, systems need to evaluate access as work unfolds.

Dynamic authority: Access issued at execution time

This means credentials are short-lived, and access is issued for a specific operation rather than granted as a standing permission. 

These patterns reduce standing privilege and narrow scope. But they don’t answer the harder question: should this action happen right now?

OpenAI describes similar principles in its system documentation, including the use of key management systems, role-based access controls, and time-bound access to sensitive resources.

Continuous, intent-based enforcement

The real challenge is deciding what should happen in the moment. Each action needs to be evaluated in context. Access may be valid, but still inappropriate.

This is where systems break down. Prompt injection doesn’t bypass access controls; instead, it works within them. The agent has permission, and the system is behaving as designed, but the outcome is still wrong.

Suppose an agent is granted read/write access to update customer records. The task is to update addresses. Instead, the agent modifies unrelated records based on flawed reasoning about data consistency. The action is allowed, but wrong in context.

When an agent invokes a tool, authenticates to a service, retrieves a credential, or performs an operation, that moment needs to be evaluated:

You can already see this in practice. In a recent security advisory on AI-assisted browsing, 1Password highlighted risks that emerge when AI systems operate with user-level permissions over untrusted content.

The takeaway is simple: you cannot rely on the model to correctly interpret rules. Controls need to be enforced deterministically. At the browser level, that means domain-bound autofill and explicit confirmation for sensitive actions.

The same principle will apply more broadly. Security has to extend beyond login into execution.

The path forward

The identity layer still matters. You need to know what an agent is, who authorized it, and what it’s allowed to do. But those are starting points, not the full answer.

Traditional IAM answers who and what. Agent systems require a third answer:

How is authority actually exercised at runtime, and should this action proceed, based on context and intent?

That is the next layer of AI security.

1Password Unified Access is built around that layer. It gives teams visibility into where agents and credentials exist across endpoints, browsers, and development environments. It secures that access through centralized governance, vaulting, and just-in-time patterns that reduce standing privilege. And it brings audit context closer to the moment access is exercised.

These controls don’t try to predict intent. They establish a foundation for governing how authority is used in practice as agent systems evolve.

The credential is the last mile of every agent action. It’s where an abstract permission becomes a real operation in a system. It’s also where trust is either maintained or broken.

Identity providers govern the front door. 1Password is building the layer that governs what happens after.