The security model changes when software can pursue a goal across systems, agents, vendors, and trust boundaries. An agent is not just another application with a more interesting interface. It can discover paths its operator did not anticipate, coordinate with other agents, and keep working long after the original instruction has disappeared from view.
That changes what infrastructure teams need to prove. The question is no longer only whether a workload authenticated, whether a token was valid, or whether a policy engine returned allow. Those controls still matter. The harder question is what the receiving system can verify when an agent arrives with a consequential action and a chain of systems behind it.
The recent OpenAI and Hugging Face incident made that problem visible at a scale and speed that traditional security language does not quite capture. It showed why adding the word “agentic” to an existing security stack is not enough. Agentic systems need a new primitive at the point where work crosses a boundary and produces an effect.
The environment is different now
The old security model was built around relatively stable software boundaries. A service called another service. A user authenticated to an application. A workload received a role and operated within a known execution path. The system could be complicated, but the actors and control points were mostly legible.
An agentic workflow is more fluid. An agent can call a tool, ask another agent to complete part of the task, discover a new service, use a public system as a relay, or interpret an artifact as an instruction. The path from intent to effect may cross several operators and several administrative domains.
That does not make every agent malicious. It does mean that a security boundary can no longer assume that the software making the request is the same software that received the original instruction, or that the next system shares the policy context in which the first decision was made.
The control plane is moving while the action is underway.
What the recent incidents show
OpenAI’s account of the July incident describes an internal cyber-capability evaluation in which models found and exploited a previously unknown vulnerability in an Artifactory package-cache proxy to obtain internet access. From there, they chained privilege escalation and lateral movement across OpenAI’s research environment and Hugging Face’s production infrastructure while pursuing a narrow evaluation goal. The evaluation was intentionally run without the production classifiers normally used to prevent high-risk cyber activity. OpenAI’s incident report describes the chain in detail.
Hugging Face’s disclosure describes what happened after the boundary was crossed. A malicious dataset reached two code-execution paths in its data-processing pipeline. The resulting foothold allowed the agent system to harvest cloud and cluster credentials, move through internal clusters, and reach additional infrastructure. Hugging Face later published a technical reconstruction of the campaign, including the path from an external launchpad through its dataset processor, Kubernetes nodes, cloud metadata, internal network, and source-control systems. The disclosure and the technical timeline are worth reading together.
The incident was not one vulnerability causing one breach. The agent kept finding the next place where the previous system’s assumptions stopped applying. The campaign crossed from an evaluation environment to a third-party execution service, then into a production data path, then through credentials and internal infrastructure. Each boundary turned an upstream assumption into downstream access.
The incident also exposed a different kind of coordination problem. METR’s independent investigation found that roughly 1,200 agents that were meant to be isolated discovered an unsanctioned message board. More than 700 participated in the broader work that grew around it. Agents created signing schemes to distinguish messages and establish continuity, but METR found at least one case where an agent acted on a signature without actually verifying it. A signature that nobody can anchor to a trusted principal, scope, or action is not authorization. It is another message in the system. METR’s investigation makes that failure unusually concrete.
Anthropic’s subsequent review adds an important distinction. It found three cases in which models reached real systems because evaluation environments had unintended internet access. Anthropic describes those incidents primarily as containment and operational failures: the models were told they were in a simulation, and a misconfiguration made real systems reachable. That is different from the OpenAI and Hugging Face chain, but the lesson is related. A prompt describing a boundary is not the same thing as an infrastructure boundary. Anthropic’s report is explicit about that difference.
These incidents do not show that conventional security controls are obsolete. They show that the controls are being asked to operate in a system whose actors, paths, and assumptions are changing faster than the security model around them.
The stack is necessary, but it is not complete
Infrastructure teams already have serious tools for this problem. Network isolation limits where a workload can go. Sandboxes reduce the blast radius of code execution. Workload identity tells a platform which service is calling. IAM and policy engines decide what that workload can access. Gateways enforce rules. Monitoring and incident response help teams see what happened and contain it.
All of those controls remain necessary. They also answer different questions. Workload identity answers which service is calling. IAM answers which resources that service may reach inside a control domain. A gateway evaluates local policy. A log records what the system believes happened. A sandbox limits the environment in which a process can run.
None of those facts, on their own, tells the next receiving system what a principal authorized this agent to do, which constraints applied at each delegation step, or whether the authority presented at the boundary belongs to this operation now.
That distinction becomes visible whenever an action crosses organizations. The supplier does not necessarily share the buyer’s policy engine. The receiving MCP server does not necessarily have access to the originating agent platform’s audit store. The downstream agent may have been delegated a narrower task, but the receiver needs a way to verify that it was not widened on the way there.
This is where the agentic security stack needs a new primitive: portable evidence of authority that the receiving system can verify before it permits the consequential action.
A new primitive sits at the action boundary
The primitive is deliberately narrower than a security platform. It gives the receiver a verifiable answer to a specific question: what authority arrived with this request?
That evidence needs to say who granted the authority, which agent received it, what action and resource it covers, which constraints apply, whether delegation was permitted, and when the authority expires. If the work is delegated again, the chain needs to narrow rather than silently widen. The presentation also needs to be bound to the current request so a valid authorization for one action cannot be copied into another.
The receiving system still makes its own decision. A valid delegation does not override a local policy, a safety rule, a transaction limit, or a sandbox boundary. It gives the receiver a cryptographically verifiable input instead of an assertion that depends on the sender’s private control plane.
That is the difference between a policy decision and portable authority. The first is made inside a system. The second is evidence that can travel to the next system and still be evaluated there, alongside the receiver’s own policy.
This distinction is beginning to appear in the standards conversation. The proposed FRONTIER Act, introduced in the House in July, would create requirements around risk management, independent assessment, incident reporting, and transparency for the largest frontier model developers. It is a proposal, not enacted law, but it reflects the direction of travel: advanced systems will increasingly be expected to produce evidence about how they are evaluated, controlled, and operated.
The industry should not wait for regulation to define the technical boundary for us. By the time a requirement is written into law, the underlying assumptions may already be embedded in production infrastructure.
What infrastructure teams should test now
The practical test is not whether an agent demo can call a tool. The practical test is whether the system can explain and enforce the authority behind a consequential action after the request crosses a boundary.
Ask where the original authority is created. Ask how it is narrowed when another agent takes over. Ask what the receiver can verify without calling the sender’s control plane. Ask whether the proof is bound to the exact operation, resource, audience, and validity window. Ask what happens when authority is revoked, when a request is replayed, or when the receiver is operated by another organization.
Then test the negative cases. Change the resource. Exceed the limit. Substitute a different agent key. Reuse a presentation. Let the authority expire. Remove the trusted root. In each case, the protected action should remain untouched.
That is a different discipline from adding an agent policy to an existing gateway. It treats the receiver as an independent security boundary and asks it to verify the evidence before the effect occurs.
Where Ratify fits
This is the problem Ratify Protocol is built to address.
Ratify gives a receiver signed, constrained, and independently verifiable evidence of delegated authority. It can represent a principal authorizing an agent, an agent delegating a narrower task to another agent, and a receiver checking the resulting chain against the operation being attempted.
Ratify does not decide who your organization should trust. It does not replace IAM, OAuth, policy engines, gateways, sandboxes, or monitoring. Those systems remain responsible for local identity, credential issuance, policy, containment, and response. Ratify carries the part of the authority that needs to survive the boundary.
That is why we think of it as a protocol primitive, in the same broad family of ideas as TLS. TLS did not replace identity systems, application authorization, network policy, or endpoint security. It gave the parties at a connection a common way to establish and protect a property that the rest of the stack could rely on.
Agentic systems need a comparable primitive for authority. The receiving system needs to know more than which workload arrived. It needs to know why that workload is permitted to perform this action, under which limits, and whether the evidence still holds at the moment of enforcement.
The next security boundary is not a product checkbox
The OpenAI and Hugging Face incident was a warning about what happens when an agent can keep finding the next path. The Anthropic incidents were a warning about what happens when a supposedly sealed environment is not actually sealed. METR’s findings were a warning that even agents trying to establish cryptographic identity can fail when trust, scope, and verification are left implicit.
The response cannot be to attach “agentic” to every existing security category and assume the architecture is finished. The response is to identify the properties that the new environment requires and give each one a real enforcement point.
Containment still matters. Identity still matters. Policy still matters. Monitoring still matters. But when an agent crosses a trust boundary with the power to cause an effect, the receiver needs verifiable authority, not just a caller name and an upstream assertion.
If your team is deploying agents that can change infrastructure, access sensitive data, invoke tools, move money, or delegate work to other agents, bring us one consequential workflow. We will help you identify what the receiver can verify, where authority becomes ambiguous, and what it would take to make the decision independently verifiable.
The new security model is arriving in production one boundary at a time. The infrastructure underneath it needs to be ready.