Governance & audit

Governance is only real if it is provable afterwards. Every tool call, every denial and every permission change is written to an immutable log scoped to your tenant. This page covers what is recorded, how to read it, and what to do with what you find.

What gets recorded

Event	Recorded
Tool call	Which tool, which connector, which credential, which person, when, and whether it succeeded.
Denial	A tool refused because it was outside the caller's role allowlist. The tool name is recorded, which is what makes denials useful rather than just noise.
Injection block	A request stopped by prompt-injection detection.
Permission change	Roles created or edited, allowlists changed, seats added or removed, keys issued or revoked.
Connector change	A system connected, tested, or disconnected.

The log is append-only. Entries are not edited or overwritten, which is the property that makes it worth anything to an auditor.

Reading it

Usage is the historical view: calls over time, by connector, tool and person. Gateway Monitor is the live view: what is happening right now. Use the first to answer questions about the month, the second during a rollout or an incident.

Four questions the log answers directly

• Did the assistant actually read our data? If there is no call in the log, it did not. It answered from general knowledge. This is the single most useful check when an answer looks suspiciously confident.
• Which agent did this? Calls carry the credential, so one key per integration turns this into a lookup rather than an investigation.
• Is a role too tight? Repeated denials on the same tool by the same person means the role does not match the job. Widen it deliberately, with the log as the evidence.
• Is a role too loose? Tools being invoked that nobody expected. Particularly worth checking after someone was granted Full Access "temporarily".

The first week of any rollout

New deployments are where roles get corrected. Spend twenty minutes in the log at the end of the first week and you will find every mistake you made in the first hour.

1. Sort by denials. Each one is a person who tried to do their job and could not. Either the role needs widening or they need a different role.
2. Look for write tools you did not expect. Anything that sends, creates or pays should be traceable to a decision someone made on purpose.
3. Check attribution. If every call shows the same identity, you are on maker-provided credentials or a shared key where you wanted per-person OAuth. Fix it now while the volume is small.
4. Find the unused connectors. Anything nobody called in a week is exposure you are carrying for free. Disconnect it.

The controls behind the log

The audit trail records what happened. These are the mechanisms that decide what is allowed to happen in the first place, each documented in full elsewhere.

Answering an auditor

The usual questions have direct answers, which is the point of recording all of this.

Question	Where the answer is
Which systems can AI reach?	Connectors. The list is the answer, and disconnecting removes the capability entirely.
Who decided that?	Permission changes in the audit log, with who and when.
What has it actually done?	Usage, filtered by connector, tool or person.
Could it move money?	Only if a write tool is on someone's allowlist. Roles & Access is the definitive answer, not an opinion.
What stopped it doing more?	Denials in the log, each naming the tool that was refused.
Where does the data live?	Data residency, and deployment models if it must stay in your network.

Log retention

Audit retention varies by plan, with the current windows listed under limits and plans. Where your own obligations require longer than your plan provides, either export on a schedule or run a deployment where the log lives in storage you control. See deployment models.