What the AIUC-1 tool-call controls actually require

Why these five sit together

AIUC-1 covers considerably more ground than tool calls. But five of its controls converge on a single question that traditional application security never had to ask: when a non-deterministic component decides what to execute, what stops it from executing something it should not?

That question does not decompose into the usual answers. Input validation assumes you can tell a malicious request from a legitimate one by looking at it, and in agent systems you often cannot, because the two are frequently identical in form. A refund request from an authorized supervisor and a refund request from someone claiming to be one look the same in the transcript. The difference is authority, not wording. The five controls below are all, in different ways, about relocating that decision somewhere the conversation cannot reach.

Control identifiers and objectives are described here in plain language. The AIUC-1 control catalogue published by AIUC is the authoritative text, and your auditor works from that, not from this page. Read both.

D003: restrict unsafe tool calls

The objective is that the agent cannot invoke a tool, or pass parameters to one, outside the permissions declared for it. The load-bearing word is cannot. A control that reduces the frequency of unsafe calls is a mitigation. A control that makes them structurally unavailable is what D003 is reaching for.

What this asks you to have in place:

• An inventory of every tool the agent can reach, including tools reached indirectly through other services, with the declared permissions for each.
• Parameter-level constraints, not just tool-level ones. Permission to call issue_refund is not permission to call it for an arbitrary amount or an arbitrary account.
• An enforcement point that sits between the agent and the tool and returns a structured denial, with a reason, when a call falls outside those constraints.
• Test results showing the denial holds when the conversation is actively trying to get past it.

The most common gap we see is that the restriction exists, and is well written, but it lives in the system prompt. That is an instruction to the model, not a restriction on the tool. It is worth having, and it is not what D003 asks for, because it fails exactly in the conditions the control exists to cover.

D004: third-party testing of tool calls

D004 asks for independent testing of the same surface. The reasoning is the standard one from every other security regime: the party that designed a defense is the worst-placed party to be its only tester, because the tests will be shaped by the same assumptions as the design.

Evidence for D004 generally needs to show four things: who did the testing and why they are independent of the team that built the agent, what the scope was and where it stopped, what the findings were with each mapped to a specific control, and when the testing was done relative to the version under assessment.

Two things that tend not to satisfy it. First, an internal red team exercise, however good, if the same organization owns both the build and the assessment. Second, a general model safety or jailbreak evaluation that never reaches the tool layer. Those evaluations test what the model will say. D004 is about what the agent will execute, which is a different surface and frequently gives a different answer.

B006: prevent unauthorized agent actions

D003 is about the tool surface. B006 is about the requester. The control asks whether actions outside the user's authority are refused rather than discouraged, which means your system needs an answer to a question most agent deployments never explicitly ask: on whose authority is this action being taken?

For evidence, an auditor is looking for an authority model that is written down (which roles can cause which classes of action), a mechanism that binds a given conversation to a verified identity rather than a claimed one, refusal evidence showing the mechanism holding under pressure, and a defined path for actions that exceed what any conversational authority should decide alone. That last one is where human approval belongs: not as a blanket requirement on everything, which teams disable within a month, but on the specific action classes where the blast radius justifies it.

B007: enforce access privileges

B007 is the per-call control. Role and scope are checked at execution, on every call, and the result is logged. It overlaps with B006 and is not the same thing: B006 asks whether the action was authorized at all, B007 asks whether the check ran and left a record every single time.

This is the control where evidence quality separates fastest, because it is fundamentally about your log. An auditor reading a well-formed authorization log can answer questions about your system without asking you anything. A log line that satisfies B007 generally carries the subject and their verified role, the tool and the parameters in scope, the decision, a machine-readable reason code for that decision, and a timestamp. Denials matter more than allows here. A log that only records successful actions cannot demonstrate that a check ran at all.

A003: contextual data safeguards

A003 covers data reaching a tool and data leaving one, and asks that it stay inside its declared boundary and classification. In an agent system this is harder than it sounds, because the agent is a general-purpose data mover. Anything it has read, it can in principle write somewhere else, and the pathway is often a perfectly ordinary tool used in a perfectly ordinary way.

Evidence here usually means classification applied to tool inputs and outputs, a declared boundary per tool (which tenant, which records, which fields), records of calls blocked for crossing that boundary, and where redaction is part of the control, evidence of what was redacted and when. The failure mode to test for is not a tool that leaks data on its own. It is a legitimate read tool and a legitimate write tool composed into a path that crosses a boundary neither one crosses alone.

What tends not to count as evidence

• The system prompt. It documents intent. It does not enforce anything, and the controls are about enforcement.
• Self-attestation. For D004 specifically, the point of the control is that someone else looked.
• A single point-in-time test. Agent behavior changes when the model, the prompts or the tool definitions change, which is to say constantly. Evidence needs a cadence.
• Screenshots without a schema. An auditor needs to know the log is systematic, not that a particular denial happened once.
• A passing result with no failures. A test run that found nothing usually means the test was not adversarial enough, and an experienced auditor reads it that way.

A minimum evidence set

If you are assembling this before an audit, the smallest set we would expect to be complete looks like:

1. Tool inventory with declared permissions, roles, parameter constraints and data boundary for each tool.
2. Enforcement point configuration, showing deny-by-default and where the check sits relative to execution.
3. Authorization log schema plus a sample containing both allows and denials with reason codes.
4. Independent adversarial test report, findings mapped control by control, with baseline results.
5. Remediation record for each finding, and a re-test result for each remediation.
6. A stated re-test cadence, and the dates of the runs that have actually happened.

Items 5 and 6 are the ones most often missing. A findings report shows an auditor what was wrong. It does not show them that anything is now right.

Where a readiness partner fits

ComplyLock builds that evidence set for one agent workflow: we run the tool surface against a private adversarial corpus to establish a baseline, close what fails at the action boundary with a provenance authorization gate, re-test each fix against the vector that broke it, and hand over the package organized control by control. We are not the certifier and not an accredited auditor. AIUC certifies, auditors assess, and independence bars them from also building your fix. See readiness vs certification for where that line sits.

Common questions

Which AIUC-1 controls cover tool calls?

Five: D003 (restrict unsafe tool calls), D004 (third-party testing of tool calls), B006 (prevent unauthorized agent actions), B007 (enforce access privileges) and A003 (contextual data safeguards). AIUC-1 covers considerably more than these, but these are the ones that govern what an agent is allowed to execute.

Does a system prompt satisfy D003?

No. A system prompt is an instruction to the model, not a restriction on the tool, and it fails in exactly the conditions the control exists to cover. D003 asks that the agent cannot invoke a tool outside its declared permissions, which requires an enforcement point between the agent and the tool that returns a structured denial when a call falls out of scope.

What evidence does D004 require?

Evidence that an independent party tested the tool-call surface: who tested and why they are independent of the build team, what the scope was and where it stopped, the findings with each mapped to a specific control, and when the testing was done relative to the assessed version. An internal red team from the same organization, or a general jailbreak evaluation that never reaches the tool layer, does not usually satisfy it.

What is the difference between B006 and B007?

B006 asks whether an action outside the user's authority is refused at all. B007 asks whether the role and scope check ran on every call and left a record. B006 is about the outcome, B007 is about the mechanism and its log. A system can pass B006 in testing and still fail B007 if the check is inconsistent or unlogged.

How often does tool-call evidence need to be refreshed?

Agent behavior changes whenever the model, the prompts or the tool definitions change, so a single point-in-time test ages quickly. We work to a quarterly re-test cadence, which matches what the controls expect of evidence, and we record the dates of the runs that actually happened rather than the policy alone.