Discussing the Trust Planes of Autonomous AI Work

Most discussions about AI agents still focus on intelligence.

Which model should we use? How good is its reasoning? Can it browse the web? Can it write code? Can it operate a computer?

Those questions matter, but they become less important once agents start performing continuous work.

The difficult question becomes: how do you safely allow an intelligent system to keep acting when a human is not constantly supervising it?

A chatbot can fail and produce a bad answer. An autonomous agent can fail and modify infrastructure, leak a credential, spend money, corrupt data, break an application, or continue making the same mistake for hours. That changes the engineering problem.

The foundation of autonomous systems therefore cannot simply be model + prompt + tools. Reliable autonomous work requires a trust architecture around the intelligence. I think that architecture has at least five fundamental planes.

1. Identity & Authority Plane#

Before asking what an agent can do, we need to know who or what is acting.

Every agent, mission, user, tool and delegated capability should have a verifiable identity. More importantly, identity must be tied to authority.

An agent working on a UI improvement mission may be allowed to:

• Read the source repository
• Create a branch
• Run tests
• Deploy to a preview environment

That does not imply that the same agent should be able to:

• Merge into production
• Modify billing
• Delete databases
• Access unrelated customer data

Authority should therefore be scoped, temporary, auditable, and revocable.

This matters most for long-running missions. If an autonomous system is expected to operate for weeks or months, its permissions cannot simply be whatever happened to exist when the process started. Authority needs lifecycle management.

Permissions expire. Missions change. Humans revoke access. Systems gain new capabilities. Policies evolve.

The identity plane should continuously answer: who is acting, on whose behalf, and what are they currently authorised to do?

Without this, autonomous agents eventually become another form of privileged service account — except considerably more intelligent and unpredictable.

2. Secrets / Vault Plane#

Identity answers who may act. The vault determines how the agent gains the credentials necessary to act.

A dangerous anti-pattern for autonomous systems is giving agents long-lived API keys, passwords or tokens directly. An agent should ideally never “own” credentials. Instead, it should request access through a credential broker:

Agent → Identity → Policy → Vault → Short-lived credential

The vault checks the identity of the mission, evaluates its authority and issues only the minimum credential required for the current operation. Where possible, that credential should be ephemeral.

A deployment agent might receive a token valid for fifteen minutes and restricted to one environment. A data-analysis mission might receive read-only database access without ever seeing the underlying database password.

This matters because autonomous systems accumulate context. Prompts, logs, shell histories, traces, temporary files and tool outputs can all become accidental places for credentials to persist. The safest secret is often the secret the agent never sees.

The vault plane should answer one question: what temporary capability does this agent need right now, not which permanent credentials should we give it. That is a subtle but important shift in how access gets designed.

3. QA / Assurance Plane#

Continuous work requires continuous verification.

Traditional software automation often executes a predetermined process: run script → check result. Autonomous agents are different. They may discover their own path toward an objective. That means we cannot always verify every individual action in advance. Instead, we must verify the outcome and the invariants surrounding it.

Every autonomous mission should therefore have something resembling a contract:

• Objective
• Acceptance criteria
• Invariants
• Regression checks
• Prohibited states
• Safety constraints
• Escalation conditions

Imagine an agent whose mission is to continuously improve the conversion rate of an ecommerce checkout. Its objective might be flexible. But its invariants should not be.

Payments must still reconcile. Tax calculations must remain correct. Accessibility cannot regress. Customer data cannot leak. Checkout latency cannot exceed an agreed threshold.

The agent should therefore continuously prove that the system remains within those boundaries. The loop becomes:

Observe → Plan → Act → Verify → Learn

rather than merely:

Observe → Think → Act

Agentic QA differs from traditional test automation here. The QA system is not simply checking whether yesterday’s scripted test cases still pass — it is continuously asking: did the autonomous work actually improve the system without breaking the things we already depend on?

Without an assurance plane, continuous autonomy eventually becomes continuous drift.

4. Execution Plane#

Intelligence needs somewhere to act. That environment should be deliberately constrained.

Depending on the mission, an execution environment might be:

• A browser
• A container
• A virtual machine
• A Firecracker microVM
• A disposable development environment
• A mobile emulator
• A remote desktop
• A specialised test laboratory

The important property is not the technology — it is containment. If an agent decides to run rm -rf, install an unknown dependency, execute generated code or visit a malicious website, the blast radius should already have been determined architecturally.

Prompt instructions such as “do not modify files outside this directory” are useful guidance, not security boundaries. A real boundary means the agent physically cannot reach anything outside the permitted environment.

This matters more as models become more capable — ironically, greater intelligence increases the need for sandboxing. We should assume that future agents will be exceptionally good at finding ways to accomplish objectives.

The execution plane therefore answers: where is this intelligence allowed to operate, and what can it physically reach?

Good autonomous systems should rely less on repeatedly telling agents what not to do and more on making dangerous actions structurally impossible.

5. Evidence Plane#

Finally, autonomy must leave evidence.

When a human engineer changes production, we expect logs, pull requests, deployment records, monitoring data and audit trails. An autonomous worker should be held to at least the same standard.

Every meaningful mission should produce durable evidence such as:

• Execution traces
• Screenshots
• Browser recordings
• Terminal logs
• Code diffs
• Test results
• Model/tool decisions
• Approvals
• Policy evaluations
• Deployment records

Evidence is what makes autonomous work inspectable and accountable, not just observable.

If an agent reports “I fixed the checkout problem,” that statement alone is not enough. We should be able to inspect what changed, why it changed, which tests ran, what passed, what failed, who approved the action, and what was deployed:

what changed → why it changed → which tests ran → what passed → what failed → who approved the action → what was deployed

Evidence does more than prove what happened. It enables learning.

Successful mission traces can become future procedures. Failures can become regression tests. Human interventions can become policy changes. Repeated incidents can modify mission constraints.

The evidence generated by autonomous work therefore becomes part of the organisation’s accumulating operational knowledge.

The evidence plane answers: can we reconstruct and prove what happened?

The Trust Substrate#

Put these five planes together and a structure emerges.

• Identity determines who may act.
• Vault determines what capabilities they may temporarily obtain.
• Execution determines where those capabilities may be exercised.
• QA determines whether the resulting work remains correct.
• Evidence determines whether we can prove what occurred.

Together they form a trust substrate for autonomous work. The architecture starts looking less like a chatbot and more like an operating environment:

Mission
  ↓
Identity & Authority
  ↓
Secrets / Capability Broker
  ↓
Controlled Execution
  ↓
Continuous Assurance
  ↓
Evidence & Learning

The model sits inside this architecture. It is not the architecture. And that distinction will only matter more.

Intelligence Is Becoming Cheap. Authority Is Not.#

AI models will continue improving. Planning will improve. Computer use will improve. Coding will improve. Tool calling will improve. Many of the capabilities that currently distinguish agent platforms will eventually become commodities.

But organisations will still face the same fundamental question: how much authority are we prepared to give this intelligence? That is where the real engineering challenge begins.

The future of autonomous systems will not be determined solely by which agent reasons best. It will depend on which systems can safely give increasingly capable intelligence real authority to perform useful work continuously.

That requires identity. It requires controlled access to secrets. It requires isolated execution. It requires continuous assurance. And it requires durable evidence.

Without those layers, we do not really have autonomous workers. We have powerful models running scripts and hoping nothing goes wrong.