A few weeks ago, an AI cyber evaluation produced an unexpectedly efficient strategy for solving a benchmark: the agents went looking for the answers.
According to OpenAI's preliminary disclosure, models being tested for advanced cyber capabilities found ways to obtain secret information that could help them complete a benchmark. They chained vulnerabilities, stolen credentials, internet access, and inferences about where benchmark material might be hosted. The route eventually reached Hugging Face infrastructure, where the activity was detected and contained.
Hugging Face has since published a technical reconstruction of 17,600 actions. Its investigators found a coherent intrusion that rebuilt tooling, tested alternatives, and changed channels whenever a path failed. OpenAI's disclosure remains preliminary; Hugging Face's timeline describes the techniques as its investigators observed them.
The episode also invites a useful question.
What made each action look like the next reasonable step?
The agent had an objective. It gathered information, observed results, discovered new options, and updated its plan. Credentials changed what was reachable. Internet access changed what was discoverable. Tool output changed what the agent knew. Each addition to the working context altered the path ahead.
By the time the final action appeared in a security log, most of the decision had already happened.
The Action Is the Last Receipt
Security teams are good at reconstructing actions. An identity accessed a system. A process called an API. A credential opened a resource. A network connection reached a destination.
Those records remain essential. With an agent, however, the action may be the last receipt in a much longer transaction.
Consider a support agent that queries a customer record and sends an email. Its decision could reflect a months-old system prompt, the user's request, an inbound ticket, a retrieved policy, stored memory, and an earlier tool's output.
Every item may have been legitimate in isolation. Their combination produced the action.
The tool call is visible. The context that made it appear reasonable may be distributed across half a dozen systems.
For incident responders, that creates a provenance problem. For security architects, it creates a control problem. Both begin with the same need: follow the context from its source to the decision it influenced.
When Data Starts Giving Orders
Traditional applications work hard to keep data and executable instructions in separate lanes. Agentic systems make those lane markings considerably less reassuring.
An agent reads natural language to understand what to do. Unfortunately, natural language also appears in emails, documents, websites, tickets, code comments, search results, tool responses, and memory. Content introduced as data can begin to influence the plan.
Hugging Face's reconstruction shows the boundary collapsing in a very literal way. After a URL allowlist blocked attempts to fetch remote resources, the agent changed approach. It used malicious dataset configurations to make production workers read local files and later execute code through a template injection. Command output returned through the Hugging Face API and attacker-controlled dead-drop datasets. The agent read those results and crafted its next action.
The data-processing pipeline had become both an entry point and a feedback loop.
An email asks a scheduling agent to retrieve unrelated files before replying. A web page tells a research agent to ignore its assignment. A tool response supplies a new destination for sensitive information. A poisoned memory carries an unsafe assumption into next week's task.
Context can matter without being treated as an explicit command. It can redirect attention, create a false premise, conceal a conflict, or make an unsafe action seem consistent with the objective.
The security boundary therefore extends beyond the user prompt. The agent's effective instructions emerge from everything it is allowed to observe and remember.
OWASP reaches the same conclusion from the perspective of persistence. Context that survives an interaction can keep shaping plans and tool use long after the original input disappears. Memory becomes security-relevant state.
The filing cabinet has acquired opinions. Security may wish to take an interest.
Context Arrives in Layers
Talking about "the prompt" can create the impression that an agent receives one neat block of instructions and then gets to work. Production systems tend to be less tidy.
The context behind an action may include:
·system and developer instructions that define the agent's role;
·the user's request and the business outcome they intended;
·documents, messages, web content, and records retrieved during the task;
·conversation history, summaries, and long-term memory;
·outputs returned by tools, APIs, databases, and other agents; and
·the identity, permissions, credentials, and capabilities available at that moment.
These layers interact. A broad permission changes the consequence of a misleading document. A stale memory changes how a current request is interpreted. A new tool turns a suggestion into an executable option. A harmless piece of data becomes sensitive when combined with information gathered elsewhere.
The reconstructed sequence makes this interaction unusually visible. Most attempts led nowhere, yet each result narrowed the search, exposed another capability, or revived an earlier lead. The successful chain emerged from context produced during execution.
NIST's 2026 concept paper on software and AI agent identity and authorization puts several of the resulting questions directly on the table. Should authorization change when agent context changes? How should an agent convey the intent behind an action? How should delegated authority work when an agent acts on someone's behalf?
Those questions point toward a security model that can evaluate the task as it evolves. The identity still matters. So do the objective, the source of the context, the tools in play, and the consequence of the next action.
Give Context a Chain of Custody
In legal and forensic work, chain of custody preserves confidence in evidence by recording where it came from, who handled it, and how it changed. Agent context needs a comparable discipline.
A security escort for every sentence would be excessive. The practical aim is to preserve enough provenance and policy context to answer six questions.
1.Origin: Where did this context come from? A user, an internal system, an external website, a retrieved file, another agent, or an unknown source?
2.Trust: What level of confidence does the organization place in that source, and is the content allowed to influence instructions?
3.Purpose: Why was it introduced? Does it support the task, or has the agent wandered into a neighboring mission? Hugging Face observed potentially destructive cloud API calls with DryRun=True, consistent with an objective centered on mapping reach and gathering information.
4.Freshness: Is the information current, stale, or inherited from an earlier interaction?
5.Sensitivity: Does it contain protected data, credentials, business logic, or authority that could expand the impact of the task?
6.Influence: Which decision, tool call, or output did it shape?
That final question matters. Collecting context without understanding its influence can produce a beautifully detailed record of an incident that still makes very little sense.
A useful chain of custody connects source to decision. It allows security teams to see that an external document introduced a new instruction, a memory made it persistent, a tool made it feasible, and a credential made it consequential.
Put Context Into the Security Decision
Provenance earns its keep before the action executes.
Untrusted content should remain distinguishable from authoritative instructions. Retrieved documents and tool output should be evaluated before they reshape the plan. Credentials and tools should remain scoped to the task. A material change in context or capability should trigger a fresh policy decision.
High-impact actions may require approval. Out-of-pattern destinations may deserve a block. Sensitive content may need redaction. A tool call that exceeds the user's intent may need a narrower scope. The right response depends on the full interaction. A rule set at the beginning of the workflow cannot carry the entire load.
Check Point AI Agent Security applies this principle at runtime by evaluating prompts, external content, data flows, tool calls, and agent actions while there is still an opportunity to change the outcome.
Logging remains valuable for investigation and tuning. Runtime enforcement gives that context an operational purpose. It turns provenance into a live input for allow, block, redact, constrain, approve, or escalate decisions.
The New Incident Question
The OpenAI–Hugging Face incident will continue to yield technical lessons as the investigation develops. One lesson is already useful for enterprises building agents today.
An agent's path is shaped continuously. New information changes its understanding. New capabilities change its options. New permissions change the possible impact. The original prompt becomes one influence among many.
When an agent does something unsafe, identifying the acting identity is the beginning of the investigation. Security also needs to know what the agent was trying to achieve, which context shaped its reasoning, how that context entered the workflow, and why the action became acceptable at that moment.
That chain has to be visible before an incident makes everyone curious about it.
