“AI SRE” is the name many vendors now use for AI that works incidents. The pitch is attractive: when an alert fires, an agent pulls the logs, metrics and recent changes, finds the likely root cause and suggests a change before your on-call engineer has finished reading the page.
Most evaluation checklists ask how accurate the agent is and how fast it gets there. Fewer ask what it keeps between incidents. For anyone responsible for production, that is the question that matters most, and it sits at the centre of zero-trust AI operations, an open specification.
What do AI SRE tools promise?
The category covers a range of designs. Most of the tools we looked at connect to observability data, deploy history, code and runbooks. When an alert fires, they investigate and report what they found. What happens next varies:
- Some stop at the report and leave the change to you.
- Some propose a change as a pull request or a command that a person applies.
- Some offer a dial that runs from reviewed recommendations up to fully automated responses.
In the vendor pages we read in October 2026, a human sign-off on changes was common. Saying what the agent holds while it waits for that sign-off was not. A human gate is now table stakes. Standing access is where the real differences sit.
Why is standing access the question to ask?
Standing access is any credential or session that stays valid between tasks: an API token in a config file, a service account the agent always runs as, a kubeconfig on the box where it lives. It is convenient, and it is the part attackers want.
Three sources make the case.
- The OWASP Top 10 for LLM applications traces “Excessive Agency” to “excessive functionality; excessive permissions; excessive autonomy”. A standing production credential is excessive permission sitting idle between incidents.
- NIST SP 800-207 warns that a software agent “may have a lower bar for authentication (e.g., API key versus MFA)” than a person, and that “an attacker could gain access to a software agent’s credentials and impersonate the agent”.
- An AI SRE reads untrusted text all day: alerts, log lines, tickets, error strings. If its process holds a production key, any instruction planted in that text has something to work with.
An approval gate does not solve this on its own. If the agent’s process holds the key, the gate depends on the agent respecting it, and the key is still within reach. The answer is to keep the key somewhere the agent cannot read. We cover that design in should AI agents hold production credentials?
What should you ask any AI SRE vendor?
Put these ten questions to every tool on your shortlist, including ours.
- Where do the credentials for my systems live, and can the model’s process ever read them?
- Does the code the agent writes run with network access? If it does, what can it reach?
- What can the agent read, and with whose permissions? Is that checked on every call, or once at setup?
- Are reads and changes separate paths? Or can the same tool do both?
- Who can approve a change, and where is that enforced? On the server, or only in a client’s user interface?
- What does an approval given inside a chat or MCP client prove? Can you require a second factor?
- Is what runs exactly what was approved? How is that checked at execution time?
- What runs unattended, without a fresh approval? Who set it up, and can the agent change it?
- What is recorded for each decision? Who can read it, and can it be altered or deleted?
- How does the agent reach systems on my private network? Through what path, and with what policy per system?
Add one more if the vendor talks about prompt injection: what happens when the agent reads instructions planted in a log or a ticket? Be wary of any answer that sounds like immunity. The honest answer is mitigation plus a limit on what a misled agent can do.
What do good answers sound like?
Good answers are specific and say where the limits are. Credentials live server-side, never in the model’s process. The agent’s code runs without network access. Reads use the requesting person’s permissions, checked on every call. Changes are proposals, approved by an authenticated person, enforced on the server, and pinned so that what runs is what was approved. Unattended work is narrow and set up by a person. Records exist and you can read them. Private systems are reached through a path you control. If a vendor cannot say where its credentials live, keep looking. For a step-by-step version of this design, see how to give an AI agent production access safely.
How GAEZLA does it
Our answers to the ten questions, briefly:
- Integration credentials stay inside GAEZLA, and the model’s process holds none. A secret a job needs is released after approval and sealed to the one enrolled Linux host that runs the job.
- The code the AI writes runs in a sandbox with no network and a time limit.
- Reads run with the operator’s console roles, checked again on every call.
- Reads run straight away. Every change is drafted as a proposal.
- An operator approves in the console or in their own MCP client. The approve and execute calls accept only an operator, and nothing in GAEZLA can approve.
- An accept in an MCP client proves the client accepted, not that a person pressed the key. Multi-factor authentication adds a push to every approval; it is a Complete-plan feature and off by default.
- The proposal is fingerprinted at approval and checked again when it runs.
- Playbook schedules set up by an operator with the schedules role run without a new approval each run. Unattended routine runs cannot change a system or open a proposal, except for mail their owner allows to recipients you allow.
- Each decision records who approved it, over which channel, the multi-factor result, when, and what ran. These are ordinary database rows, deleted with their case, and we do not call them tamper-proof.
- Systems on your network are reached through the appliance’s reverse tunnel, so nothing connects in, behind a separate access policy per system and the system’s own login. Endpoints you can reach directly can also be connected without it.