Skip to main content

Connect an AI agent

Give an AI agent access to your governed records, without giving it access to anything the person operating it cannot already see.

Before you start​

  • A tenant with records loaded.
  • An account that can sign in, with the permissions the agent should have — the agent gets exactly these and nothing more.
  • An MCP-capable client.

1. Understand what you are granting​

Worth being precise about, because it is the opposite of the usual integration:

  • The agent acts as the signed-in user. It carries that user's identity to every request.
  • There is no service account. The endpoint has no privileged identity of its own.
  • Granting agent access grants no data access. The user's existing permissions already decided that.

The practical implication: to limit what an agent can reach, limit the user it runs as. That is the whole control.

2. Get a token​

The agent authenticates as the user through your identity provider, exactly as the console does. There is no separate credential type and no development shortcut that behaves differently from production.

3. Configure the client​

Point the client at the endpoint and supply the token. The client discovers the available tools; there is no separate schema to install.

4. Ask a question​

Start with something that would be hard against raw source systems:

How many customers do we have?

The answer counts entities, not source rows — the platform resolved the duplicates, so the count is of real people rather than of records.

Then:

Does this person appear anywhere else in our data?

This is the question source systems structurally cannot answer.

5. Verify governance holds​

The summary card as a restricted account sees it, with three identifiers redacted to their last four characters What a restricted account receives: Social Security Number, Tax ID and National ID redacted to their last four characters. An agent acting for this person receives exactly this.

The same summary card as an authorised account sees it, with the three identifiers in full The same record, the same card, an authorised account — the same three fields in full. Masking is applied when the response is generated, so the difference is decided server-side rather than by the screen.

Do this once. It is the check that matters.

Sign in as a user with restricted permissions — one for whom a sensitive field is masked — and ask the agent for that field.

It returns the masked value. Not an error, not a refusal, and not the real value: the agent received the mask and can only repeat it. There is nothing for it to reconstruct from, because masking is applied when the response is generated rather than per endpoint.

Then ask a read-only user's agent to change something. It is refused, in every autonomy mode — autonomy governs whether a person is asked, never what the request is allowed to do.

This is the demonstration worth doing for stakeholders

Two users, the same question, different answers — each correct for who asked. It shows the governance property directly rather than describing it.

6. Check the audit log​

Every agent action is recorded, attributed to the user whose identity was used. There is no separate, less-traceable path.

Next​

Last verified against commit 952ed91b (2026-08-03)