Integrating Asenion AI Guardian

Asenion AI Guardian is delivered as an MCP service — an advisor and witness service your agent or application calls. There is no separate console to open: you integrate Guardian programmatically, calling its tools from your own code at the points where your agent takes a bounded action.

This page describes the tools Guardian exposes and when to call each. For the record they produce and how it is verified, see Witness records; for where Guardian sits in the platform, see Asenion AI Guardian.

The three tools at a glance

Tool	Call it	What it returns	Emits a witness record?
`list_policies`	To see which policies are loaded	Each policy in the bundle, with a `has_evaluation` boolean	No
`consult_policy`	Before a bounded action	The guidance that applies, and a witness record with an `event_id` — never a verdict	Yes
`evaluate_response`	After the agent’s response	A paired witness record linked to the prior `consult_policy` `event_id`	Yes (paired)

The signatures, at the level the tool contract states, are:

list_policies(filter?)
    -> each policy in the loaded bundle, with a has_evaluation boolean
    -> does not emit a witness record

consult_policy(<the bounded action to consult on>)
    -> the guidance that applies, and a tamper-evident witness record (with an event_id)
    -> never returns a verdict

evaluate_response(<the agent response>, phase: "test" | "monitoring")
    -> a paired witness record, linked to the prior consult_policy event_id
       via a hash-committed paired_event_id

The angle-bracketed inputs mark what the contract names without fixing a field-level schema here; the complete request and response shapes are part of the integration contract you receive from the team (see What these docs do not yet cover).

list_policies — see what is loaded

Call list_policies to enumerate the policies in the loaded bundle, with optional filtering. Each policy comes back with a has_evaluation boolean, telling you whether that policy has an evaluation available. list_policies is for discovery and orientation; it does not emit a witness record.

consult_policy — before a bounded action

Call consult_policy before any bounded action. It surfaces the guidance that applies and produces a tamper-evident witness record of what was consulted and what guidance was returned. It never returns a verdict. This is the call that puts guidance in front of your integration at the moment it matters, and it is the call that leaves the runtime evidence described in Witness records.

evaluate_response — after the response

Call evaluate_response after an agent response to emit a paired witness record, cryptographically linked to a prior consult_policy event by a hash-committed paired_event_id. evaluate_response requires an explicit phase, declared on the call — see the signature above for the accepted values. The pairing is what turns a before-consultation and an after-evaluation into one verifiable unit.

Quick start — integrate in five steps

Get an endpoint. A Guardian endpoint is provisioned for your organization, and your integration is given the credentials to authenticate to it, by the Asenion team (see below).
Add Guardian as an MCP server in your agent or application, alongside the other tools it calls.
Consult before a bounded action. At the point where your agent is about to take a bounded action, call consult_policy, naming the action. Guardian returns the guidance that applies and a witness record with an event_id.
Act on the guidance. Your integration reads the guidance and decides what to do — proceed, change course, or hand off to a person. Guardian does not decide this for you.
Evaluate after the response (optional). Once the agent has responded, call evaluate_response with a phase to emit the paired record, linked to the consultation by its event_id.

list_policies can be called at any time to see what is loaded; it produces no witness record.

A worked example

Suppose an agent in a support workflow is about to send an external email that includes a customer’s account summary. Before it sends, your integration consults Guardian:

consult_policy("send an external email containing a customer's account summary")
    -> guidance: the policies that apply to external disclosure of account data
    -> witness record: event_id = evt_9f2c...

Guardian did not decide whether the email may be sent. It surfaced the guidance that applies and produced a witness record of the consultation. Your integration reads that guidance and chooses how to act — for example, redact the account numbers, route the draft to a human reviewer, or proceed as written. Whichever it does, the witness record already proves what guidance was on the table at the moment of the decision.

If you then want an after-the-fact record of what the agent actually produced, evaluate the response:

evaluate_response(<the email the agent drafted>, phase: "monitoring")
    -> a paired witness record, linked to evt_9f2c... via a hash-committed paired_event_id

Now there is a verifiable before-and-after for that one action: the guidance that applied when the agent acted, and the response evaluated against it afterward — bound together so the pairing cannot be altered without detection. How that pairing is verified is described in Witness records.

When to call each

Orienting — list_policies when your integration needs to know which policies are loaded and which carry an evaluation.
Before acting — consult_policy at the moment of a bounded action, before the action is taken.
After responding — evaluate_response once the agent has responded, to close the pair with a paired record linked to the consultation.

consult_policy is the call you make at the moment of the bounded action; evaluate_response adds the paired record once the agent has responded; list_policies never produces a witness record and can be called freely.

What your integration does with the guidance

Guardian surfaces guidance and witnesses what happened. It does not act for you:

Your integration decides how to act on the guidance — Guardian’s record proves what was surfaced, and when.

This is the keystone of integrating Guardian. Your code holds the guidance Guardian returned and chooses what to do with it — proceed, change course, hand off to a person — and Guardian’s witness record proves what guidance was surfaced, and when. Guardian does not block or approve actions on its own. Building the action on top of the guidance is your integration’s responsibility, and keeping that responsibility on your side is what makes the witness record trustworthy: it records what was advised, not an action taken on your behalf.

What these docs do not yet cover

Guardian’s three tools are documented above. Some of what you need to run Guardian in your own environment is arranged with the Asenion team rather than published here:

Getting an endpoint. How a Guardian endpoint is provisioned for your organization, and how your integration authenticates to it, is set up with the Asenion team. Contact support@asenion.ai.
Full request and response schemas. The signatures above state the tool contract at the level these docs cover — the tools, what each produces, and the witness-record guarantees. The complete field-level request and response schema for each tool is part of the integration contract you receive from the team, not restated here.
No graphical console. Guardian is integrated through its MCP tools, not a screen. These docs describe the service you call, not a user interface, because Guardian’s runtime surface is the tool contract itself.

Where to go next

Witness records — what consult_policy and evaluate_response produce, and how it is verified.
Asenion AI Guardian — the consult, guidance, and witness-record loop in context.
Trust & Security — the platform-wide evidence model and reviewer’s view.
Glossary — Guardian, consultation, and witness record in one place.