Most teams give an AI agent production access the wrong way round. They hand it an account, watch what it does, and add rules when something goes wrong. The rules end up in a prompt, and a prompt is a request, not a control.
We think the safe order is the reverse. Decide what the agent may never do, enforce that outside the model, and then give it as much reach as is useful. This guide walks through that order in seven steps. It is vendor-neutral: the steps work with any agent and any stack. At the end we show how we built them into GAEZLA, but the pattern is the point. It is zero-trust AI operations, an open specification.
Where should you start?
Step 1: start read-only, on one system, with one real question.
Most of the value of an AI in operations comes from reading. Finding what changed, pulling the logs, comparing configuration and tracing a root cause are all reads. An agent that can read across your systems already spares your team from opening console after console.
Pick the system that hurts most when it breaks. Pick a question your team asked during the last incident. Let the agent answer it with read access only, and check the answer against what you know. You will learn more about the agent’s usefulness from that than from any demo.
What account should the agent use?
Step 2: a dedicated, least-privilege account per system.
Never let an agent borrow a person’s admin account. Create a service account for each system you connect, with the narrowest permissions that answer your questions. Read-only where the system allows it.
This is plain zero trust. NIST’s zero trust architecture says access “should also be granted with the least privileges needed to complete the task”. A separate account per system also means that access to one system never implies access to another, and that you can revoke one connection without touching the rest.
Where should the credentials live?
Step 3: in a server-side gate, never with the agent.
The account’s credentials should sit in a service that makes the calls on the agent’s behalf. The agent asks; the gate checks the request against the permissions of the person who asked, and calls the system itself. The model never sees the secret.
If a credential is anywhere the agent can read, assume it will eventually be found and used. Should an AI agent hold production credentials? explains why we treat this step as the one that matters most.
What about the code the agent writes?
Step 4: run it in a sandbox with no network.
Agents write code to filter, join and summarise what they read. That code should run where it can work on the data it was handed and cannot open a connection. Give it a time limit too. Then nothing the code finds, and nothing a steered run wants to send, has a way out.
How should changes work?
Step 5: every write becomes a proposal a person approves.
When the agent wants to change something, it should not call the write API. It should produce a proposal: the exact change, the reason and the evidence it relied on. A person reads it and approves or rejects it.
Two details make this a control rather than a ritual.
- The platform enforces who can approve. The approve action must refuse the agent, its tokens and any automation. The OWASP guidance on excessive agency recommends exactly this: require approval for high-impact actions, and enforce authorization in downstream systems instead of relying on the model.
- What runs is what was approved. Fingerprint the approved content at approval and check it again just before it runs. If anything changed, the approval no longer applies.
What should you record?
Step 6: keep a record a reviewer can follow later.
For each change, record who asked, what the agent read, what it proposed, who approved it, over which channel, and what ran. Be honest with yourself about what kind of record it is. A database row is useful evidence; it is not tamper-proof unless you made it so. Know your retention, too.
How do you widen access safely?
Step 7: one system and one kind of change at a time.
Once reads on the first system are useful and trusted, allow changes there, behind the proposal path. Review the first proposals closely. Then add the next system. Keep a per-connection switch that turns changes off for a system without removing its reads.
Watch for one failure mode as you grow: approval fatigue. If every small change needs a fresh, unexplained approval, reviewers start clicking through. Proposals should carry their evidence so a review is quick, and related changes should travel together. Approval fatigue and the human in the loop covers how to keep review meaningful.
A short checklist
- The agent reads with the requesting person’s permissions, re-checked on every call.
- Each system has its own least-privilege account; read-only where possible.
- Credentials sit in a server-side gate the agent cannot read.
- Model-written code runs with no network and a time limit.
- Every write is a proposal with its evidence and exact content.
- Only a verified person can approve, and the approved content is fingerprinted at approval.
- Each decision records approver, channel and what ran.
- Changes can be switched off per system.
How GAEZLA does it
GAEZLA follows the same seven steps. Each integration exposes the vendor’s whole published API to the AI, and reads run inside the operator’s scope, with their console roles checked again on every call. Integration credentials stay inside GAEZLA and the AI never holds one. Code the AI writes runs in a sandbox with no network and a time limit.
Every change the AI asks for is drafted as a proposal that an operator approves, in the console or in their own MCP client. The proposal is fingerprinted at approval and checked again at execution. An integration can be set read-only; changes there are refused. Each decision records who approved it, over which channel, any multi-factor result and what ran. Multi-factor authentication on approvals is optional and part of the Complete plan.
To try the order on your own systems, start a trial or bring one real incident to a walkthrough.