Skip to main content

Docs · Trust

AI agent governance: authority, actions and evidence

An AI agent needs a defined permission to act, not just a useful answer. Good governance connects the purpose of the work, the people who may decide, the tools the agent can use and the evidence of what happened.

By Nebula Platform Pty Ltd. Sources checked 15/10/2026. This guide is practical evaluation guidance. It is not a certification, independent assessment or claim that Nebula or any deployment meets a standard.

What is AI agent governance?

AI agent governance is the set of responsibilities and controls that determine what an agent may read, propose and change. It covers the operating conditions around a model: identity, tools, data access, approvals, records and the ability to stop an action. A model's confidence does not give it permission to commit another party to a decision.

The distinction matters in delivery work. A model may correctly identify a changed completion date while the person asking about it has no authority to accept a variation. Reading the change, proposing a response and changing the agreed plan are separate acts.

Define authority before connecting tools

Use this checklist to review one real workflow before expanding an agent's access. It is a set of questions to ask, not a certification scheme.

  1. Purpose. Name the outcome and the work the agent may support.
  2. Principal. Identify the person or organisation on whose behalf it acts.
  3. Scope. List the records, tools and operations it may use. Separate reading from writing.
  4. Conditions. Record the active document version, limits, expiry and required approvals.
  5. Action. Show the exact proposed change and its recipient before approval.
  6. Evidence. Keep the source, approval, attempted operation and confirmed result connected.
  7. Recovery. Define how to interrupt, revoke or correct an operation, including actions that cannot be undone.

OWASP's AI Agent Security Cheat Sheet recommends scoped tool permissions, explicit approval for high-impact actions, validation of untrusted inputs and outputs, and monitoring. These are controls to test in the actual workflow, not a badge a supplier earns by mentioning them.

A worked change-control example

Consider an illustrative supplier email asking to move delivery from week 30 to week 32 while commissioning remains in week 36. This is a hypothetical review exercise, not a customer outcome or a statement about a live project.

The agent first identifies the affected requirement and the source of the request. It then shows the possible schedule consequence. The request remains a supplier assertion until the applicable agreement and authorised parties establish its status.

A useful approval record names the proposed date, the document version being changed, the approver and the scope of that approval. If the source changes after approval, the system should check the basis again before execution. If the operation is retried, the retry should not create a second change.

Questions to put into an agent demonstration

  • What happens when a document contains an instruction to ignore the approval process?
  • Can a user who may view an engagement also change it, and where is that distinction enforced?
  • Does an expired or revoked approval stop the action?
  • Is a model proposal distinguishable from an accepted decision in the record?
  • What happens if the tool times out after completing the action?
  • Can the operator show a refusal and its reason, as well as a successful run?

Use synthetic material for these tests. A useful demonstration shows the expected result and the actual record, not only the agent's explanation. Assessing answer quality is a separate task covered in Model trust and evaluation.

Inspect Nebula's published evidence

Nebula's trust page explains how authority stays with the parties and how work remains connected to its source. The public reading example lets a visitor inspect a prepared reading. Security and data handling describes published access and processing boundaries. These pages support specific claims. A reading example alone does not establish that every possible agent action is safe.

For procurement, use the AI evidence checklist to separate requirements, implemented controls and independent assurance. For a workflow-specific discussion, contact Nebula.