Every ops team I talk to wants the same thing from AI: let it do the legwork. Read the hypervisor, the load balancer, the identity provider and the cloud account. Find out what is going on, and draft the change.
Nobody I talk to wants to hand it an admin account to do that, and neither do I. I have spent more than 25 years in infrastructure and security, and a good part of that revoking standing access someone once thought was harmless. A model that takes instructions from whatever text it reads is the last thing I would give standing access to production.
So when we built GAEZLA, we started from the other end. The AI gets real reach across the estate. It never gets the keys.
Zero trust, applied to the AI
Zero trust usually describes how you treat people and devices: verify every request, grant the least privilege, assume a breach. We apply the same rules to the AI and treat it as an untrusted actor.
In practice that comes down to three rules:
- It works inside your scope. The AI can only use what the person who asked is allowed to use, and that is checked again on every call.
- Its code has no way out. Anything the AI writes runs where it cannot reach the network or a credential.
- It can ask, never approve. Every change it wants waits for a person.
The reason is simple. An AI reads tickets, logs, mail and web pages, and any of them can carry instructions meant for it. We treat recalled memory as data rather than instructions, and the AI can only mail recipients you allow. That lowers the risk without removing it, so we designed for the day the AI gets something wrong.
Reach without keys
The reach comes from each vendor’s own API. An integration exposes the vendor’s whole published API, so the AI can ask the questions your best engineer would ask, in the system that knows the answer. Reads inside your scope run directly, and the evidence lands in a case, so every answer shows where it came from.
The keys stay somewhere else. Integration credentials are stored server-side and used by the platform; the model never sees them. When the AI writes code to sift what it read, that code runs in a sandbox with networking off and a time limit. It can work on the data it was handed. It cannot call out, and there is no password in reach to find.
Hosts get the same treatment. Agents run only playbooks that are signed and verified on the host, and a playbook reaches a host only after a person approves it. When a job needs a secret, the value is read once after approval, sealed to the one enrolled Linux host that runs it, and removed from the output.
Every change is a proposal a person approves
When the AI wants to change something, it writes a proposal: the exact API change, playbook or pull request, the reason, and the evidence behind it. The proposal is fingerprinted at approval, so it cannot be tampered with on the way, and what runs is exactly what was approved.
Only a person can approve. That happens in the console, or in a prompt in your own MCP client, signed in as yourself. Nothing in GAEZLA can approve a proposal, the AI included.
Each decision is recorded: who approved, over which channel, whether a step-up was used, and what ran. If you want a second factor on every approval, multi-factor authentication on approvals adds one on the Complete plan.
- You ask, in the console or in your own MCP client.
- The AI reads each system through the vendor’s API, holding no keys.
- The AI drafts the change: the exact content, ready for review.
- A person approves it. If no one does, nothing changes.
- GAEZLA runs exactly what was approved, nothing more.
- The decision is recorded: who approved, over which channel, and what ran.
The AI works in steps 2 and 3; nothing crosses step 4 without a person, and what runs is checked against the fingerprint that person approved.
What it costs, and what it does not solve
A person in the loop is slower than an agent that just acts. For changes to production we think that is the right trade, and reads, which is where an investigation spends its time, still run without waiting for anyone.
The approval is only as good as the reviewer. The AI can propose something wrong; the gate makes sure a person sees it before it runs, not that the person catches every mistake. That is why a proposal carries its evidence and the exact content, so the review is a read rather than a guess.
Zero trust here applies to the AI, not to us. You still choose what to connect, with which account and how much privilege; least-privilege service accounts, read-only where you can, are the right start. And an approval accepted in an MCP client proves the client accepted it, not that a person pressed the key, unless multi-factor authentication is on. I would rather say that here than have your security team find it.
The principle
Give the AI as much reach as you like. Give it no keys, no network for its code and no vote. That is zero-trust AI operations, now an open specification, and it is the only way I would let an AI near my own production.
If you want to see it, bring one real incident to a 30-minute walkthrough at gaezla.com/contact. We will show you what the AI reads, what it proposes, and who approves it.