How to answer examiner questions about a LangChain agent's tool calls

The questions examiners tend to ask

Examiners rarely ask about your framework. They ask about actions. When an agent can send an email, query a database or change a record, the question becomes what the agent was permitted to do, what it actually did, and whether you can prove both.

Those questions fall into a few categories. The first is scope: which tools could the agent call, and was that list limited to what the task required? OWASP's guidance on excessive agency uses a simple example. An agent that needs read access to a products table should not be able to insert, update or delete records. The second is authority: which identity and permissions authorized a given call, and under whose approval did a consequential action proceed? The third is control: which policy applied, and was the call allowed, redacted, blocked or escalated for human approval? The fourth is detail: what arguments went in and what came back? The fifth is durability: how long is the evidence retained, and where does it reside?

OWASP's Agentic Evidence work frames the underlying need well. Knowing what an agent did is no longer sufficient. Teams must establish why an action occurred, which identity and permissions authorized it, and whether the evidence can be trusted. Because agents use the output of earlier calls to direct later ones, the evidence is a series of decisions, not a single event.

Mapping each question to the evidence it needs

Use this map to check whether your current records can answer each question without reconstruction by hand. Framework-specific mappings, such as to NIST or the EU AI Act, should be confirmed against the official text before you cite them to an examiner.

• What tools could the agent call?: A per-agent tool inventory with least-privilege scoping, enforced at runtime so the list reflects what was actually callable.
• Who or what authorized the call?: The caller identity and permissions evaluated for that specific call, plus the approver where a human approved it.
• Which policy applied?: A policy identifier and version attached to each decision, so the rule in force at that time can be reproduced.
• What was the outcome?: The decision (allowed, redacted, blocked or escalated), the arguments as evaluated, the tool result and a timestamp.
• How long is it kept, and where?: Documented retention periods, storage location and a stated approach to redacting sensitive arguments.

Putting policy enforcement in the execution path of a LangChain agent

OWASP's guidance is direct on placement. Validation and authorization should run in code outside the model, next to the tool that causes the side effect. Agent-level input and output checks have limited coverage, so they should not be the only control. For LangChain, OWASP recommends the human-in-the-loop middleware to pause configured tool calls for review, with a caveat that matters in an audit: every sensitive tool must be configured, and a prompt asking for human review does not itself stop execution. A tool that was never configured is a tool that never paused.

The exact interception points depend on your LangChain or LangGraph version, so confirm them against the official documentation. The design principle does not change. The decision must be made by trusted code before the tool executes, and it must write its own record.

• Inventory every tool each agent can call and remove anything the task does not need.
• Place a policy check at the tool-call boundary that evaluates the proposed operation, target, arguments and the caller's authority, not keywords in the user's prompt.
• Configure human approval for every sensitive tool, and bind each approval to the specific action and arguments so it cannot be reused for a different call.
• Write one evidence record per call at the moment of the decision, covering allowed, redacted, blocked and escalated outcomes alike.
• Store records durably, outside the agent process, with defined retention and location.

Enforcement-generated evidence versus after-the-fact logging

Callbacks, traces and application logs are useful for debugging, and they can show that a tool was invoked. They are weaker as audit evidence for a specific reason: they are produced by the same component whose behavior is being examined. OWASP Agentic Evidence draws this line explicitly, separating component-generated assertions from independently verifiable evidence. An enforcement point is a stronger source because the decision and the record come from the same trusted code in the path of the call, not from a later reconstruction. That is an inference from OWASP's provenance framing rather than a stated standard, and OWASP describes this initiative as still developing its taxonomy.

The practical difference shows up when an examiner asks about a call that did not happen. A trace may show nothing for a blocked call, or may show a call that the application chose to record. An enforcement record shows the proposed call, the policy that applied and the decision to block it. Answers become consistent and reproducible because they come from one source rather than from callbacks, tracing tools and application code assembled after the question arrives.

What the record contains, and the retention and redaction decisions

A workable tool-call record includes tool identity, arguments, policy version, decision, approver where applicable, timestamp and outcome, together with the caller identity and permissions that authorized the call. Treat this as a design choice to validate with your own examiners, not a fixed schema.

Two decisions affect defensibility. The first is redaction. Tool arguments and outputs often contain sensitive data, so storing them verbatim can create a second exposure. Redacting before storage, and recording that redaction occurred, lets you show what was evaluated without retaining what should not be kept. The second is retention and residency. Decide how long records are kept, where they are stored and who can alter them, then write it down before the first examination. Records that can be edited by the application they describe are hard to defend.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. Each decision produces audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls.

Limits of tool-call evidence

Be precise about what this evidence shows. A tool-call record answers questions about individual calls: what was proposed, what policy applied, what was decided and what happened. It does not by itself show end-to-end behavior across a multi-step workflow, nor does it establish the business transaction a series of calls belonged to. If an examiner asks about that, say so plainly and describe what you can show.

The same restraint applies to regulation. The EU AI Act is Regulation (EU) 2024/1689, dated 13 June 2024, and as of November 2026 the Commission presents it as the first legal framework on AI. Before you map records to its record-keeping or human oversight provisions, read the specific articles in the official text and confirm the application dates that govern your system. Evidence design should follow what the examiner is entitled to ask, not what is convenient to produce.