Before the tool call: how to test an AI agent's runtime control

A document can tell an AI agent to do something its user never requested. The dangerous moment is not when the model reads that sentence. It is when the agent turns it into a file read, an email, a database query or a payment.

The short answer: put an enforceable decision at every consequential tool call, then test that decision under hostile input, lost connectivity and tampered context. A policy hook is useful only if the agent honours its verdict and downstream systems still enforce the user's permissions.

In September 2026, the OWASP GenAI Security Project added the Agent Control Standard (ACS). ACS defines a way for an observed agent to send lifecycle events to a separate Guardian, which can allow, deny, modify, defer or ask for approval before an action proceeds. It is a wire specification and set of conformance profiles, not a certification that any particular agent is safe.

This distinction matters. A decision log is still just a log if an unauthorised tool call can bypass it.

Follow the authority, not the prompt

Consider a support agent asked to summarise an invoice. The invoice contains an instruction to export a customer list. That sentence came from task data, not from the authorised user. If the agent has a database export tool, the security question is whether the export is stopped at the action boundary.

Boundary	Representative action	Security question
User intent	Summarise the invoice	What was actually authorised?
Lower-trust input	Invoice text requests a customer export	Is data being promoted into authority?
Policy point	Inspect the proposed tool call, arguments and destination	Does the call exceed the user's scope?
Effect	Allow or deny before execution	Did the export actually stop?

This example is illustrative. It is not an Arica engagement or a reported ACS exploit.

OWASP's Excessive Agency guidance identifies excessive tool functionality, permissions and autonomy as conditions that turn model mistakes into damaging actions. It recommends narrow tools, least-privilege identities, user-context execution and authorisation in the downstream system. ACS can provide the checkpoint; those underlying controls still have to exist.

What ACS does and does not prove

The ACS v0.1.0 conformance document defines ACS-Core as the mandatory baseline. It covers the handshake, request envelope, lifecycle hooks, five dispositions, replay protection, a signed decision channel and the requirement that the observed agent wait for and honour the Guardian's verdict. Trace and inventory capabilities are separate profiles.

The same document is candid about two limits. A conformant Guardian may still have a permissive policy. Conformance profiles are also self-declared in v0.1.0, without an independent verification body or shipped conformance suite. For a buyer or security reviewer, the claim is a starting point for a test, not the test result.

The published reference implementation README, checked on 24 September 2026, calls out its own gaps: its wire is not authenticated and its default decision-failure posture is to proceed. That describes the reference implementation as documented on this date. It should not be read as a property of every ACS deployment. It does show why the failure path belongs in any acceptance test.

Five tests before you trust the checkpoint

1. Prove a normal request still works. Start with a task the user is entitled to perform. Capture the initiating user, session, tool, resource, arguments and policy version. The Guardian should allow the exact action, and the downstream service should independently authorise it. This gives you a clean baseline before adding adversarial content.

2. Make lower-trust content request an extra action. Put a harmless instruction in a test document or tool result that asks the agent to call a different tool or read an unrelated resource. Use a sandbox and dummy data. The Guardian should deny the resulting call because it exceeds the user's intent or resource scope. Test the complete proposed action, including arguments and destination, rather than searching for suspicious words.

3. Check the verdict at execution time. Try an action that should be modified or sent for approval. Verify that the actual tool receives the modified arguments, or that approval is bound to the exact action the reviewer saw. A displayed warning is not enforcement if the original call still runs. ACS defines modify and ask dispositions; their implementation must be verified end to end.

4. Disconnect the Guardian. Time out the policy service immediately before a state-changing tool call. Decide in advance whether the action should stop or proceed, then verify that the configured failure posture is applied and recorded. ACS v0.1.0 documents proceed as the default on decision failure. For high-impact actions, a fail-closed posture may be appropriate, with an explicit availability trade-off and recovery path.

5. Challenge the decision channel and the evidence. Replay a request, alter an argument after approval, and verify that the agent rejects a decision that does not match the call it is about to execute. Check signatures, request IDs, timestamps, policy references and audit completeness. Keep secrets out of general-purpose logs. ACS-Core requires baseline message signatures and replay rejection; inspect whether the deployed system actually implements them.

A practical release decision

An agent can have a runtime policy hook and still be overprivileged. The release gate should therefore have two independent answers: did the Guardian stop the unwanted call? and would the downstream system have rejected that call anyway? If only the first answer is yes, the Guardian has become a single point of failure. If only the second is yes, the agent can still attempt out-of-scope actions and create operational noise.

This is also why static jailbreak scores are not enough. In a 2026 NIST CAISI analysis, a public competition produced more than 250,000 agent-hijacking attempts across 13 frontier models, with at least one successful attack found against every target model. The result says nothing about ACS specifically. It does support a broader testing principle: adversarial inputs change, so controls need to limit the consequence of a model following one.

Scope of this note: this is Arica's analysis of public OWASP and NIST material, checked on 24 September 2026. We did not run or benchmark the ACS reference implementation for this article. Configuration and repository status may change after publication.

For teams preparing an agent release, our AI security research shows how we separate raw detector output from validated findings. To scope a system-specific review, talk to the team and begin with the smallest meaningful authority path.

Primary sources

1. OWASP GenAI Security Project, Agent Control Standard resource page, 1 September 2026.
2. Agent Control Standard repository and reference implementation README, checked 24 September 2026.
3. ACS v0.1.0 Conformance Profiles, checked 24 September 2026.
4. OWASP LLM06:2025 Excessive Agency.
5. NIST CAISI, Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, 23 March 2026.