Agentic AI systems interact with external tools such as APIs, databases, and communication channels. Articles 12 and 18 of the EU AI Act require that every tool interaction is governed through registries and permission boundaries, and that the agent's reasoning chain is recorded in immutable trace logs.
A tool registry is a governed artefact that documents every external tool available to an agentic AI system.
A tool registry is a governed artefact that documents every external tool available to an agentic AI system. The technical sme maintains this registry, recording for each tool: its name and description; the API endpoint or interface specification; the permissions it grants (read, write, delete, execute); the data it can access or modify; the rate limits and quotas enforced; and the risk assessment for the tool's misuse potential.
Agentic systems interact with a wide range of external tools, including APIs, databases, file systems, communication channels, and code execution environments. Each tool extends the agent's capabilities while simultaneously introducing a new risk surface. The registry serves as the authoritative record of what the agent is permitted to interact with and under what constraints.
The tool registry is version-controlled alongside the system code and referenced in aisdp Module 3. Adding a new tool to the registry is classified as a significant change that triggers the governance pipeline's risk gate. Removing a tool is a routine change unless it affects the system's ability to fulfil its intended purpose. Agentic AI Systems and EU AI Act Compliance covers the broader governance framework for agentic systems.
Each tool in the registry has explicit permission boundaries that the action execution layer enforces at the infrastructure level.
Each tool in the registry has explicit permission boundaries that the action execution layer enforces at the infrastructure level. A recruitment agent's database tool may have read access to candidate records but no write access to employment contracts. A clinical decision support agent's knowledge retrieval tool may access medical literature but not individual patient records.
Permission boundaries are implemented through infrastructure-level controls: IAM policies, API scopes, and database role restrictions. They are not implemented within the agent's own reasoning. An agent that reasons about its permissions and decides to escalate them is exhibiting precisely the behaviour the boundary is designed to prevent. The permission enforcement must be external to and independent of the agent. Conformity Assessment Procedures addresses how these boundaries are evaluated during assessment.
Every tool call an agent makes is validated against the action schema before execution.
Every tool call an agent makes is validated against the action schema before execution. The validation checks that the tool is present in the registry, that the action is permitted by the schema, that the parameters conform to the schema's type and range constraints, that the preconditions are satisfied, and that the agent has not exceeded its iteration or rate limits.
Failed validations are logged and blocked. The agent receives an error response indicating that the action was not permitted. This ensures that even if the agent's reasoning leads it to attempt an action outside its permitted scope, the infrastructure layer prevents the action from executing.
Article 12 requires automatic recording of events relevant to the identification of risks and substantial modifications.
Article 12 requires automatic recording of events relevant to the identification of risks and substantial modifications. For agentic systems, the relevant "event" is not a single inference but a chain of reasoning and action that may span seconds or hours and involve dozens of tool calls.
The reasoning trace log captures, for each agent execution: the initial trigger (user query, scheduled task, or system event); each planning step where the agent states its reasoning about what to do next; each tool call with the tool name, parameters, and return value; each observation where the agent interprets the tool call result; each decision point where the agent reasons about which action to take based on observations; any error or exception encountered; and the final outcome including the conclusion, actions taken, and result delivered. Monitoring and Reporting Requirements covers broader monitoring obligations for high-risk systems.
The trace is structured as a sequence of timestamped, typed events in a defined JSON schema. Each event is linked to the execution identifier, enabling reconstruction of the complete reasoning chain from the log.
Reasoning traces are written to append-only storage to guarantee immutability.
Reasoning traces are written to append-only storage to guarantee immutability. The traces are retained for the aisdp evidence period, which is ten years under Article 18. Storage and access controls follow the audit persistence layer architecture.
The traces serve three distinct compliance purposes. First, they satisfy Article 12's requirement for automatic recording of relevant events. Second, they support post-incident investigation by providing a complete record of what the agent did and why. Third, they enable post-market monitoring by revealing whether the agent's reasoning patterns are changing over time.
Tool-use governance and reasoning trace logging form complementary controls for agentic AI systems.
Tool-use governance and reasoning trace logging form complementary controls for agentic AI systems. The tool registry and permission boundaries define what the agent is permitted to do. The validation layer enforces those boundaries in real time. The reasoning trace captures what the agent actually did, creating an immutable record for compliance and investigation.
Together, these controls ensure that agentic systems operate within their defined scope and that every action is both authorised before execution and recorded after execution. The tool registry is reviewed as part of the quarterly governance cycle, and the reasoning traces provide the evidence base for that review.
No. Permission enforcement must be external to and independent of the agent. An agent that reasons about its permissions and decides to escalate them is exhibiting precisely the behaviour the boundary is designed to prevent. Use IAM policies, API scopes, and database role restrictions instead.
The validation failure is logged and the tool call is blocked. The agent receives an error response indicating the action was not permitted. This prevents the agent from executing actions outside its permitted scope regardless of how its reasoning led to the attempt.
First, Article 12 compliance through automatic recording of relevant events. Second, post-incident investigation providing a complete record of what the agent did and why. Third, post-market monitoring to detect whether the agent's reasoning patterns are changing over time.
Through infrastructure-level controls such as IAM policies, API scopes, and database role restrictions, not within the agent's own reasoning.
Every tool call is checked against the action schema to verify the tool is registered, the action is permitted, parameters conform to constraints, preconditions are met, and rate limits are not exceeded.
The initial trigger, each planning step, every tool call with parameters and results, observations, decision points, errors, and the final outcome.
Ten years under Article 18, written to append-only storage for immutability.
Human Oversight
