An open specification

Zero-trust AI operations

The AI gets the reach, and never the trust.

An AI that reads your logs, alerts and tickets reads things anyone could have written, and it can be talked into things. Zero-trust AI operations treats it as an untrusted actor. It acts only as the operator who asked. It holds no credential. It has no network of its own. Only an operator can approve a change, exactly as it will run. Every decision is recorded where the AI cannot change it. The five rules are an open specification on GitHub, free for any team to use and for any vendor to be held to.

Read the specification Follow a request

Definition

What is zero-trust AI operations?

Zero-trust AI operations is zero trust applied to the AI that runs your IT operations: the AI gets the reach, and never the trust. It reads your systems through the platform and drafts changes. It holds no credential, has no network of its own, cannot approve a change, and every decision is recorded where it cannot change it.

Zero trust was written for people and devices. Zero-trust AI operations applies it to the AI that acts on your systems, as five rules any team can hold a tool to. The fullspecification is open on GitHub under CC BY 4.0: the testable requirements behind each rule, a conformance template, a crosswalk toNIST SP 800-207 and the OWASP Top 10 lists for LLM and agentic applications, and a 25-question checklist for anyone buying an AI operations product.

An open specification maintained by GAEZLA · Version 1.0.0-draft.1 · Updated 19 October 2026

The five rules

The five rules of zero-trust AI operations.

Act only as the person who asked.
Every request is authorised for the people involved, by the platform, when it happens. The AI has no authority of its own, and what it reads, and anything derived from it, stays with the people entitled to it.
NIST SP 800-207, tenet 4: Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
Never give the AI a credential.
The platform attaches credentials to each request outside the model, and removes from what the AI reads the credentials it holds and those it can recognise, in the forms it documents.
NIST SP 800-207, tenet 3: Access to individual enterprise resources is granted on a per-session basis.
Give the AI no network of its own.
The AI reaches your systems only through the platform. Its code has no network, nothing in its answers runs as code, and nothing in them is fetched automatically except by the platform itself or from allow-listed destinations.
NIST SP 800-207, tenet 2: Network location alone does not imply trust.
Let only a person approve a change, exactly as it will run.
A person with the authority to make the change approves it, with user verification bound to that proposal. What runs is the content they saw, against the same targets, once, before the approval expires. Unattended change exists only within automations and classes that people define and bound in advance.
NIST SP 800-207, tenet 6: All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
Record every decision where the AI cannot change it.
What the AI was asked, what it read, what it proposed, who approved it, how, and what ran, kept out of the AI's reach.
NIST SP 800-207, tenet 7: The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

The rules are quoted from the specification, which turns each one into requirements and ends it with tests a buyer can run or ask the vendor to show. The tenets are quoted from section 2.1 of NIST Special Publication 800-207, Zero Trust Architecture (August 2020). Both are free to quote with a link.

How GAEZLA does it

The five rules, enforced in GAEZLA.

Rule	What it means for an AI	How GAEZLA enforces it
Act only as the person who asked	A request may come from a model that was talked into it. It gets no authority of its own.	Every operator signs in, and the MCP endpoint has no anonymous path. Every read runs with that operator's own permissions, checked again on every call. The AI cannot claim a role, a purpose or a permission it does not have.
Never give the AI a credential	Anything the AI holds, it can leak.	Integration credentials stay inside GAEZLA and are attached to each call outside the model. When a job needs a secret, the proposal names it. After approval, the execution worker reads the value in memory, seals it to the one enrolled host that runs the job, and removes it from the output.
Give the AI no network of its own	An AI that can reach both your systems and the internet can carry what it read out of the building.	The code the AI writes runs in a sandbox with no network. Your systems are reachable only through GAEZLA, and the systems on your own network only through the appliance's reverse tunnel, so nothing connects in. Mail goes only to recipients you allow.
Let only a person approve a change	Assume the model will one day be wrong, or talked into something.	Every change is drafted as a proposal that shows exactly what will run. Only an operator can approve it, in the console or in their MCP client, with multi-factor authentication if you require it. The proposal is fingerprinted at approval, so it cannot be tampered with on the way. Nothing in GAEZLA can approve a proposal.
Record every decision	You must be able to show what the AI did, and who let it.	Each decision records the operator who approved it, over which channel, under which requirement, when, and what ran. The investigation trail is visible live while the AI works, and the evidence on a case is append-only.

Mechanisms

Follow one request, one secret and one approval.

A request

You ask in the console, or from your own MCP client.
The AI writes code against the GAEZLA SDK. That code runs in a sandbox with no network.
Each SDK call runs inside GAEZLA, with your permissions. GAEZLA attaches the system's credential there, and the sandbox never sees it. A change stops here and becomes a proposal.
For a system on your own network, the call goes down the appliance's reverse tunnel, so nothing connects in.
The system checks its own login and applies its own permissions.
The read comes back as the vendor's own data, not a summary of it.

A secret

The AI looks up the secret by name. It sees names and labels, never values.
It writes the job with the secret as a named variable, and proposes it for one host.
An operator approves that exact job in the console. Nothing has been read yet.
GAEZLA reads the value once and seals it to the enrolled host that will run the job.
The host decrypts it in memory, runs the job and removes the value from the output. The grant is deleted.

Jobs that need a secret run on enrolled Linux hosts.

An approval

proposedThe change, its reason, its evidence from the case and its exact content.
awaiting approvalWaiting for an operator. Nothing has touched your systems.
approvedBy an operator, in the console or in their MCP client, with multi-factor authentication if you require it. The proposal is fingerprinted at approval, so it cannot be tampered with on the way.
executedGAEZLA runs exactly what was approved, nothing more.
recordedWho approved it, over which channel, under which requirement, when, and what ran.

Boundaries

What the AI can do, and what it cannot.

It can

Read every connected system through its vendor's own API
Draft changes, playbooks and pull requests
Run scheduled routines that read, and send only the mail you allow
Recall what earlier cases learned

It cannot

Reach your network, or any network, from the code it runs
See an integration credential or the value of a secret
Approve anything: nothing in GAEZLA can approve a proposal, and the approve call refuses machine tokens
Change a connected system without an operator's approval
Rewrite the evidence on a case: it is append-only

Approaches

Three ways to put AI into operations.

Each fits somewhere. The question is how much reach the AI needs, and what stands between it and production.

	Read-only AI assistant	Autonomous agent with a service account	GAEZLA
Can it make the change?	Recommends. An operator makes the change by hand.	Makes the change itself.	Drafts the exact change and runs it once an operator approves.
What keys does the AI hold?	Read credentials.	A standing privileged account.	None. Credentials stay inside GAEZLA or sealed to the host that runs the job.
If it is manipulated	Gives a wrong answer.	Can act on it before anyone looks.	Can propose something wrong; cannot run it.
Best for	Teams that only want faster answers.	Narrow, well-understood, low-risk tasks.	Production estates where the AI must do real work.

Read the full comparison

Questions, answered

Zero-trust AI operations, one question at a time.

Before an AI gets access to production: 25 questions
The specification's buyer checklist, for any AI operations tool: what a good answer sounds like, and the red flags. Free, no sign-up, printable.
Letting an AI near production without trusting it
Why we give an AI real reach into production while it holds no keys, its code has no network and only a person approves a change, and what that costs.
Should an AI agent hold production credentials?
No. A credential in an AI agent's reach is the root risk. Here is why, and how to give an agent real reach into production without handing it the keys.
How to give an AI agent production access safely
A vendor-neutral guide: start read-only, keep credentials out of reach, run model-written code with no network and make changes wait for a person.
How do you enforce human approval for AI changes?
Asking an AI to be careful is not access control. How to make human approval something the platform enforces, and the honest limits you should know.
What can a prompt-injected AI do to your infrastructure?
An injected AI with keys can do whatever those keys allow. Take away the keys and the right to approve, and it can only propose. How to keep it there.
How does NIST SP 800-207 zero trust apply to AI agents?
The seven tenets of NIST SP 800-207 mapped to an AI agent that works on production, and where the mapping breaks: an agent can take orders from text.
MCP security: what operations teams need to control
What changes when an AI reaches production through MCP: credentials in reach, tools wider than the job, approval in the client, and controls that hold.
How do you keep a human in the loop without approval fatigue?
Approving every AI action wears reviewers down until a yes means nothing. Gate only changes, make each review a quick read, keep approval meaningful.
Does an AI SRE need standing access to production?
AI SRE tools promise faster root cause and changes. Before you connect one, ask what access it keeps between incidents. Ten questions to put to any vendor.
AIOps vs zero-trust AI operations: what is the difference?
AIOps groups alerts and cuts noise. AI that investigates and changes systems needs more: zero trust for the AI itself. How they differ and who needs which.

For your security review

The questions we get first.

Is this zero trust in the NIST SP 800-207 sense?

We apply its tenets to the AI's access. Every request runs as the operator who asked. The AI holds no standing privilege and no credential. Each system is reached on its own terms. Every change the AI asks for is approved by an operator and recorded. Device posture checks and dynamic access policies are not part of GAEZLA's own policies.

What happens if the model is prompt-injected?

It can propose something wrong. It cannot run it: the proposal shows exactly what would run, and only an operator can approve it, with multi-factor authentication if you require it. Recalled memory is treated as data, never as instructions, and mail can only go to recipients you allow.

Where does the AI run?

You bring your own AI: your own Claude seats, or an Anthropic-compatible endpoint you choose. The investigation agent runs on your appliance, and an MCP client runs wherever you run it. Both reach your systems only through GAEZLA.

Can we switch the AI's write access off?

Yes. Integrations carry a read-only switch, and with it on, changes there are refused. Integrations you have not configured are hidden from the AI, and every change on any integration still needs an operator.

What do you record?

Every proposal and decision: who approved it, over which channel, under which requirement, how long the decision took and what ran. Evidence on a case is append-only.

The full control list is on the security architecture page. Our DPA and sub-processors are under Legal.

Next step

Bring your security team's questions.

Thirty minutes, one real request: what the AI reads, what it proposes, who approves it and what gets recorded. Or start a trial and run it on your own estate.

Book a walkthrough Start a trial