Trusting AI does not mean believing it is always right.
Trusting AI means knowing:
- what it can do,
- what it cannot do,
- when it must ask,
- what evidence it used,
- who approved the action,
- how to inspect what happened.
That is a very different kind of trust.
The bank analogy
A bank does not trust employees by giving everyone vault access.
It creates roles:
- teller,
- supervisor,
- auditor,
- fraud analyst,
- branch manager.
Each role can do different things. Some actions need approval. Some require evidence. Everything leaves a record.
AI agents need the same structure.
Five levels of authority
Use this simple ladder:
| Level | Plain English | Example |
|---|---|---|
| Look | AI reads or summarizes | ”Find the order” |
| Draft | AI prepares but does not send | ”Draft the email” |
| Ask outside | AI calls an external service | ”Check shipping status” |
| Act for user | AI does something on delegated authority | ”Schedule the meeting” |
| High-impact act | AI changes money, access, legal state, or sensitive data | ”Issue refund” |
These are discussion labels, not a universal safety order: a read or external lookup can disclose protected data, and drafting into a shared app can already change state. In ContextOS v1, these roughly illustrate approval-mode compatibility labels: read_only, local_write, network, delegated, and destructive. Native policy uses the more precise ActionRisk dimensions underneath the plain-English ladder.
Non-technical leaders can use this ladder in meetings. It makes risk concrete.
Ask: what should require a gate?
A required approval gate pauses the dependent action until current entitled approval exists. Some missing evidence or prohibitions cannot be cured by asking a human to click approve. Already authorized narrow work may proceed without repeated confirmation when no mandatory gate applies.
Gate examples:
| Situation | Why gate? |
|---|---|
| Money moves | Financial risk |
| Customer receives message | Relationship risk |
| Account access changes | Security risk |
| Employee data used | Privacy risk |
| Legal or compliance claim made | Regulatory risk |
| Ambiguous policy | Judgment risk |
| Missing evidence | Accuracy risk |
The gate is not a failure. It is part of the system.
What an approval should show
A useful approval request includes:
- proposed action,
- reason for action,
- evidence used,
- policy or rule,
- possible side effect,
- what happens if rejected,
- who is approving,
- final receipt.
Bad approval:
Approve refund?
Good approval:
Approve INR 9,000 refund for Order 123. Evidence: identity verified, order delivered late by 6 days, refund policy section 4.2 applies, amount exceeds self-serve threshold. If all current controls pass, payment system will attempt this exact refund under stable operation R-912. If its acknowledgement is lost, the system will show an unresolved outcome and reconcile with the provider before any eligible retry.
The second version states scope and uncertainty. Bind the exact amount/currency, order, payment destination, nested arguments, actor and evidence to the stored proposal and approval. A changed action invalidates it. Check current approver entitlement, distinct quorum and expiry/revocation; a copied approval flag or an idempotency key cannot establish those facts.
Receipts matter
After AI does important work, it should leave a receipt.
ContextOS calls this a DecisionRecord.
A receipt answers:
| Receipt question | Why it matters |
|---|---|
| What work was requested? | Scope |
| What evidence was used? | Grounding |
| What tools were called? | Action trace |
| What policy applied? | Governance |
| Who approved? | Accountability |
| What changed? | Impact |
| Can we replay it? | Audit and learning |
A receipt is necessary for inspectability, but it cannot authenticate its own source, prove active containment or atomically redeem an approval. Use protected current authority, operation and budget stores and trusted observations. Tool success, partial effect and unknown provider outcome must remain distinct.
Boundaries are not bureaucracy
Boundaries make AI useful.
Without boundaries, people either overtrust the system or refuse to use it.
With boundaries, people know:
- this AI can summarize but not send,
- this AI can draft but not approve,
- this AI can recommend but not execute,
- this AI can execute only under this threshold,
- this AI must escalate these cases.
Clear boundaries increase adoption because users understand the tool.
Trust checklist for business teams
Before launching AI into a workflow, ask:
- What can it read?
- What can it draft?
- What can it send or change?
- What requires approval?
- What evidence is mandatory?
- What must it refuse?
- What receipt does it leave?
- Who reviews mistakes?
- How can we stop or roll back the system?
Add who owns scheduled/proactive work, how a revoked mandate reaches every child, what proves actual stop, and what happens after a provider acts without replying. Resume needs current owner/ancestor authority, exact approval, active execution/credential/data boundaries, external preconditions and original shared spent/reserved capacity under current worker fencing. A stop request or version rollback does not prove reversal.
Common misunderstanding
People often think the choice is:
Fully automate or do nothing.
The better choice is:
Decide which parts can be assisted, drafted, delegated, or gated.
Start with bounded useful work. A reviewed future grant can expand scope; good results cannot remove a current mandatory condition. Data collection, model/reviewer processing, tools, telemetry, cache, memory, exports and delegated copies need eligible purposes/readers/processors and retention. Pending or externally unknown correction/deletion receipts mean propagation is incomplete.
The execution contract, exact profiles and conformance evidence connect these questions to useful positive and required denial cases in the actual deployment. A reference demo or high score cannot certify runtime enforcement.