Five Questions Security Teams Must Be Able to Answer About Every AI Agent

Written by

Security teams can tell you what an AI agent is allowed to do. But can they prove what it did?

Recent agent incidents show why that distinction matters. Organizations need evidence to explain what an agent was allowed to do, what it did and why.

While conducting internet-based research into government spending on medicines, an OpenAI agent encountered access restrictions on an Australian government portal, found a way around them and accessed non-public files. In July, OpenAI agents under evaluation found ways around controls intended to prevent direct internet access and used vulnerabilities in shared infrastructure to reach the internet and compromise Hugging Face systems.

In a UK AI Security Institute (AISI) evaluation, an agent attempted to insert malicious code into an open-source project and created fake identities to persuade a human maintainer to approve it.

The incidents were different, but they point to a common problem: once agents interact with systems, tools and people beyond their immediate task, policies alone are not enough. Organizations need evidence.

AISI’s monitoring detected unusual data leaving a test system through Tor, an anonymity network that can obscure the source of internet traffic, and the team contained the incident within an hour. Hugging Face publicly disclosed its intrusion on July 16; OpenAI connected its agents to the incident on July 20.

 In Australia, the unauthorized access occurred on June 18, but Services Australia was not notified until September 10.

How to Mitigate Agentic AI Threats

Security teams need evidence to detect, authorize, contain and reconstruct consequential agent actions. They should ensure they are able to answer the following questions:

Who is This Agent?

Not which model powers it, but who owns it, who approved it and what identity it uses. Agents operating through shared service accounts or borrowed user tokens make attribution difficult.

Security needs a unique agent identity, a named owner, an approval record and a mapping to its credentials.

What is it Allowed to do Right Now?

Effective authority should match the current task, not simply the access granted at deployment. A research agent does not need payment APIs. A coding agent should not inherit a path to production.

The Hugging Face incident shows how a legitimate integration can become an unexpected route to broader access. OpenAI reported that agents exploited vulnerabilities in Artifactory, an internal package-management service, to establish an unauthorized communication channel and obtain unintended internet access before reaching third-party systems.

The evidence should show the effective permissions, tool allowlist, token scope and any time- or task-bound restrictions in force when the action occurred.

Why Was This Specific Action Allowed?

When an agent invokes a tool, API or sensitive data source, the authorization decision should be independently auditable. It should be made and recorded by a policy layer rather than delegated to the model’s own reasoning.

The authorization record should show the decision, policy version, relevant inputs and any required human approval.

This matters when several permitted steps combine into an unintended outcome. A blocked request should not quietly become an instruction to find another route without that change being visible and governed.

What Did the Agent Consume Before Acting?

Documents, API responses and messages from other agents can influence the next decision. In a multi-agent system, one agent’s output can become another agent’s input, extending the chain of influence across system boundaries.

An independent investigation by METR and Redwood Research found that roughly 1200 agents used an unsanctioned message board to exchange more than 70,000 messages and files during the evaluation; roughly 700 went on to participate in the attack on Hugging Face.

The provenance record should show where material inputs came from, when they were retrieved, which agent consumed them and whether they influenced a decision or entered memory.

Without provenance, investigators can reconstruct what an agent did but not reliably establish what influenced the action.

Can We Stop it and Reconstruct What Happened?

A kill switch is necessary but not sufficient. Security teams need telemetry connecting the task, tool calls, authorization decisions, data access, inter-agent messages and final actions.

The organization should have a linked trajectory record, along with a tested procedure to halt the agent, revoke its credentials and cancel queued actions.

AISI’s response shows the value of this visibility: monitoring surfaced suspicious activity quickly enough for the team to contain it within an hour. The Australian incident shows the opposite risk: when agent activity is not surfaced quickly, notification and investigation can lag far behind the event.

Test What You Can Prove

Not every agent needs the same level of telemetry. A low-risk agent that summarizes public documents does not require the same controls as one that can move money, modify records, send external messages or access production systems. High-impact agents should meet higher evidence standard.

Each question also needs a named owner. Identity may sit with identity and access management (IAM), authorization with a risk owner, runtime enforcement with the platform team and trajectory logging with security operations. A least-privilege policy does not prove the agent had least privilege at the time of an incident. A logging standard does not prove the relevant trajectory was captured.

Start with one production agent and one consequential action it took last week. Answer the five questions using only records that exist today. Can your team show who the agent was, what it could do, why the action was permitted, what influenced it and how to reconstruct the sequence?

If not, the gap is not simply documentation. It is the organization’s ability to demonstrate control over an autonomous system.

That should be the standard for agent security: not whether a policy exists, but whether the organization can demonstrate what its agents were allowed to do, what they did and why.

What’s Hot on Infosecurity Magazine?