GAEZLA
Menu
Book a walkthrough

Checklist · free, no sign-up

Before an AI gets access to production

AI can now do real operations work: read across your systems and draft the change. The question is no longer whether the model is clever enough. It is what happens when it is wrong, misled or compromised. Ask every vendor these 25 questions, including us, and write down the answers. They are part of the openzero-trust AI operations specification, and each one names the requirements it tests.

By Rune Tipsmark, Founder of GAEZLA · Updated

How to use it. Ask every vendor the same questions, in writing. During a trial, ask them to show rather than tell, and test the product, not the model: when the AI declines to do something, that tells you about the model, not about what the product prevents. A plain "no, and here is how we limit the risk instead" is a respectable answer; a vague answer, or one that turns out to be untrue, is the real red flag.

Rule 1. Act only as the person who asked

  1. Whose permissions does the AI use on each system, and what enforces them? R1.1 R1.2 R1.3

    Good answer
    The requesting person's, checked by the product on every request, for that session only, down to the namespace, mailbox or index, and never more than that person's own account on the system allows. For systems with neither per-person accounts nor a way to ask what a person may do, the vendor says that granularity is set by your organisation's mapping in the product. A revoked permission takes effect within an hour at most.
    Red flag
    A broad service account with no per-person check, or "the agent knows what it is allowed to do".
    Ask them to show
    As a user without access to a system, have the AI read it. The product refuses.

  2. How do you take an operation away from the AI, and what happens to a command nobody has classified? R1.4 R1.5 R0.2

    Good answer
    Operations not offered do not exist for the AI. Every request is classified as a read or a change by what it does; commands and queries count as changes unless the product enforces that they only read; and if a check cannot complete, nothing runs.
    Red flag
    A line in the system prompt, "GET requests are reads", or "the tool says it is read-only".

  3. What can the AI do when nobody is watching, such as on a schedule? R1.7 R4.10 R4.11

    Good answer
    Read and propose, within a scope the trigger states. Anything that changes a system unattended is an automation or a narrow class of change that people defined in advance, with limits and an expiry of at most a year. Each run uses the current permissions of the person responsible, and stops if that person leaves.
    Red flag
    Unattended remediation, with the AI deciding what to fix.

  4. Who else can see what the AI read on my behalf? R1.10 R1.11

    Good answer
    Only people with access to what it came from, down to the namespace, mailbox or index where the system allows, including anything the AI later derives from it through memory or summaries, unless someone with that access shares it deliberately. Other customers never can, including other customers of the same service provider, unless the customer it came from has permitted it. In a shared channel, the AI works only with what everyone there may see.
    Red flag
    Memory, knowledge or search shared across users or customers.

  5. Can you stop everything at once, or one person's work, and narrow what the AI can reach? R1.12 R1.13 R1.8 R1.9

    Good answer
    One action ends every session, withdraws pending proposals, stops running changes and suspends approved changes, automations and classes: new requests are refused at once, and the rest completes within 60 seconds, apart from documented operations and steps named as having to finish safely. The same works for one person, for everyone acting for a service provider, and for one system or resource. Sessions end within 24 hours and when the person's account is disabled, requests are rate-limited, and you can restrict the AI to less than the requesting person's own access, down to resources.
    Red flag
    "We would redeploy", or sessions that never end.

Rule 2. Never give the AI a credential

  1. Can the model or its code ever see a credential the product uses, including the key for the model provider? R2.1 R2.2 R2.5

    Good answer
    No. The product attaches credentials to each request, outside the model, never places them where the AI can read, and replaces them if a system echoes them back.
    Red flag
    API keys in the agent's environment variables or configuration files.
    Ask them to show
    From the AI's execution environment, list the environment and files. No credential appears, apart from a session identity that is useless elsewhere.

  2. What does the AI see when it reads a system that holds credentials, or resets one? R2.6 R1.6

    Good answer
    Credential values are replaced before they reach the AI: every credential the product itself holds, in common encodings; fields the system marks as secret; key material; authorization headers, tokens and password hashes; and, for each kind of system the product supports, a stated list of formats such as cluster secrets, cluster configuration files, device configurations and infrastructure-as-code state. A reset is approved on its own, and the new value never reaches the AI. The vendor says plainly that credentials in free text are caught only on a best-effort basis.
    Red flag
    "The model knows not to repeat them."
    Ask them to show
    Read a cluster secret and a network device configuration through the AI. The values are replaced.

  3. How does an approved job get a credential it needs? R2.3

    Good answer
    Preferably the product makes the connection itself, so the job never holds a credential. Otherwise the proposal names the credential; the value is released only after approval, only to that job, preferably as a credential created for it and expiring when it ends; a script that runs on your host receives only such a per-execution credential; and the AI learns only whether it succeeded unless a person releases the output.
    Red flag
    Credentials passed in plain text through the conversation.

  4. What identity does an AI session use, and what happens if it is copied? R2.4

    Good answer
    One bound to the session and the person who started it, accepted only by the product, never passed on to your systems, which ends with the session, and which the AI cannot read or which is useless from anywhere else.
    Red flag
    A long-lived bearer token shared by every run.
    Ask them to show
    Copy the session's token, if it is readable at all, and use it from another machine. It is refused.

Rule 3. Give the AI no network of its own

  1. Can the AI reach your private network directly? R3.1

    Good answer
    No. It reaches your systems only through the product, which also runs and classifies any diagnostics such as ping or name lookups.
    Red flag
    "It runs inside your VPN."

  2. Where does code the AI writes run, and can it, or a browser it drives, reach the internet or look up a name? R3.2

    Good answer
    In an isolated environment with no network, and no DNS, apart from the product's own interface. Any browser it uses is run by the product, which keeps the cookies.
    Red flag
    A shell on a server with internet access.
    Ask them to show
    From the AI's environment, request an address of your choosing that is not allow-listed, and look up a name in a domain you control. The request fails, and no lookup reaches your name servers.

  3. Can the AI browse the web in the same session in which it reads your systems? R3.5

    Good answer
    Only in a way that what it read cannot steer: it queries a disclosed search or lookup service that keeps queries to itself and opens only the results or sources you allow-list, or research happens in a separate session with no access to your systems, or a person approves each request. The vendor says the query itself still reaches that service.
    Red flag
    "Yes, it looks errors up online while it investigates", with any address it likes.
    Ask them to show
    Have the AI read a value from one of your systems, then fetch an address that contains it on a site that is not allow-listed. It cannot, or a person must approve it.

  4. Which channels can carry anything out, and can anything in the AI's answers load or run by itself? R3.3 R3.4 R3.8

    Good answer
    A short, named list of channels. Each is limited to destinations you allow-list, with a stated audience that may see what the AI read, or each message is approved. No interface, chat or mail integration loads images or link previews from the AI's output, except the product's own and allow-listed addresses, nothing in an answer runs as code, and links to other destinations cannot be clicked directly. Destinations that act on what they receive, such as a chat bot that runs commands, get only fixed content.
    Red flag
    "It can post to any channel it has access to", or AI answers that render remote images.
    Ask them to show
    Make the AI's answer include an image from a server you control, and open it everywhere the product shows answers. Your server receives nothing.

  5. Which third parties receive what the AI reads, and who chooses the account? R3.6

    Good answer
    A complete list: model, embedding, search, lookup, filtering, telemetry, tracing, hosting and delivery providers, with account, region, retention, training use, who else can see the content, and whether the account is shared with other customers. The product, not the AI, chooses the account for every request, and you can use your own.
    Red flag
    Only the model provider is named, or the AI could use a key it found in a document.

Rule 4. Let only a person approve a change, exactly as it will run

  1. Can the AI change anything without a person approving it first? R4.1 R4.11 R0.1 R0.3

    Good answer
    Only within automations and narrow classes of change that people defined in advance, limited to named operations and targets, with a maximum scope, rate and expiry. Fixed rules decide what falls in a class, never the AI or another model, and no setting the AI can reach turns approval off.
    Red flag
    "Low-risk changes run automatically", with the AI deciding what counts as low risk.
    Ask them to show
    Ask the AI to make a change. Nothing changes until a person approves.

  2. Is what runs exactly what was approved, including everything it downloads, and only once? R4.2 R4.3 R3.7

    Good answer
    Yes. Approval binds to a digest of the exact content, including its timing and a bounded retry policy; every package and image the product fetches is pinned by digest, never by version or tag alone, and anything a host fetches that cannot be pinned is flagged; plans are checked again before applying, and computing them is itself controlled; the approval covers one run; and code the product runs can reach only the destinations it declared, with any destination not checked against what the session read marked as such. Parts that run on your hosts are flagged as having the host's network.
    Red flag
    The approval covers a description, and the details are filled in afterwards, or a script pulls the latest version at run time.
    Ask them to show
    Alter a proposal after it has been approved. Execution refuses.

  3. What happens if the target changes, or the approval sits unused for a week? R4.4 R4.5

    Good answer
    Targets are bound by identifiers that are not reused, or by a fingerprint the product computes, and the state the change depends on is bound too; all of it is checked again at execution. Approvals, retries included, expire within 30 days.
    Red flag
    Targets by name only, and approvals that never expire.

  4. Who can approve, and how do you know it was them and not software? R4.6 R4.7

    Good answer
    Only a person who holds permission to make the change, directly or through your just-in-time process, and who has access to everything the session read or was deliberately given it, checked again when it runs. Every approval is confirmed with user verification, such as a passkey, bound to that specific proposal and used once; you can restrict which authenticators count; adding an authenticator needs an existing one, or a sign-in restricted to attested authenticators, or a documented out-of-band process; and disabling an account disables its authenticators.
    Red flag
    "They are signed in", an approve or deny push, an API key that can approve, or "anyone on the team can approve anything".
    Ask them to show
    Try to approve with a machine token, as a person without permission, and by driving a signed-in browser with an automation tool. All are refused.

  5. What does the person approving actually see? R4.9 R4.8

    Good answer
    The exact content as plain text, with hidden characters made visible; the targets, the identity it runs as, the credentials and destinations it uses, and any part that runs on a host; timing, retries and any step the stop action lets finish; destinations not checked against what the session read; what else the session proposed and what it read; and evidence drawn from the systems themselves, with untrusted sources marked. Anything the AI wrote is marked as such. Several proposals approved together are each shown in full and can be rejected one by one.
    Red flag
    A summary the AI wrote, presented as the reason to approve.

  6. Can the AI change the product's configuration, its own instructions or memory, and can a tool server change its tools? R4.10 R4.11 R4.12 R4.14

    Good answer
    Configuration, including schedules, classes, allow-lists, account mappings and restrictions, changes only through proposals a person with that permission approves, and the AI cannot disable anything. Configuration kept in a repository takes effect only after such a person confirms the difference. What the AI writes to memory is marked as its own, is never shown as evidence and never becomes instructions without approval, and updated tool definitions need approval too. Classes allow only listed operations, parameter values and people-controlled attributes, never a free-form command.
    Red flag
    Yes, directly.

  7. Can you require someone other than the requester, or two people, to approve some changes, and can you freeze changes? R4.13 R4.15

    Good answer
    Yes, for kinds of change you choose, including a change authority that does not itself hold admin rights and with whom the requester shares the proposal, and freeze periods in which nothing runs.
    Red flag
    No way to separate the person who asked from the person who approves.

Rule 5. Record every decision where the AI cannot change it

  1. What is recorded? R5.1 R5.2 R5.3

    Good answer
    Every instruction to the AI and every answer, with the model and version used and the instructions it was given. Every request it made or was refused, with its parameters. For every proposal, including rejected, withdrawn and expired ones: the exact content, the targets, the evidence, who decided, how they verified, what ran and the result. Every configuration change, and who disabled what.
    Red flag
    A chat transcript, or nothing for reads.

  2. Can the AI alter records, and how are they kept? R5.4 R5.5 R5.6 R5.7 R5.8 R5.9

    Good answer
    The AI cannot touch them. Text in them is shown as plain text everywhere, including exports. The vendor names how records are protected, they are kept for at least a year unless law or a collective agreement requires less, they are not dropped because of volume, a person's own sessions are private to them by default, and they stream to your own logging or SIEM platform within a stated delay.
    Red flag
    "Immutable", with no mechanism behind the word.

The vendor

  1. What can the vendor itself reach in your environment?

    Good answer
    A specific answer, how that access is controlled and recorded, a public list of sub-processors and a data processing agreement.
    Red flag
    "Nobody can access anything", or no answer.

  2. Will they put their answers in writing, including what the product does not prevent?

    Good answer
    Yes: a dated statement with evidence for each requirement, such as a conformance statement against the specification, the settings that would weaken it, and the risks it leaves.
    Red flag
    "We're fully compliant", with nothing written down.

Appendix: how GAEZLA answers, gaps included

We built GAEZLA around these rules, so here are our own answers. Where we fall short, we say so. The rules are zero-trust AI operations, and the full specification is open on GitHub.

1–5
Every read runs with the requesting operator's own console roles, checked again on every call, and integrations you have not configured are hidden from the AI. Every change is drafted as a proposal. A routine only reads; the one thing it may send is mail, under its own approval, to recipients you allow. A schedule runs the stored, signed playbook an operator set up. Gap: GAEZLA has no single action that ends every session and withdraws every pending proposal at once. An operator is cut off by disabling their account in your identity provider, and an integration by setting it read-only or removing it.
6–9
The model's process holds no credential. Integration credentials stay inside GAEZLA and are attached to each call outside the model, and tool results are masked for secret-named fields, bearer tokens and API keys before the model sees them. A job that needs a secret names it in the proposal; the value is read once after approval, sealed to the one enrolled Linux host that runs it, and removed from the output. Each run's token is bound to its case and the operator who started it, and is revoked when the run ends. Gap: masking free text is best effort, and a job that receives a secret runs with the agent's privileges.
10–14
The code the AI writes runs in a sandbox with no network, and your systems are reachable only through GAEZLA. Mail the AI sends goes only to recipients you allow. The model runs on your own seats or an endpoint you choose, under your provider account, and our sub-processors are public. Gap: the AI runner's own research tools can look things up on the web while it investigates, and the specification's separate-session rule for that is not met yet.
15–21
Every change is drafted as a proposal, fingerprinted at approval and checked again when it runs. Nothing in GAEZLA can approve one, and approve and execute refuse machine tokens. A proposal carries its reason, risk, target, exact content and evidence from the same case, with optional preconditions, stop conditions and rollback. Schedules an operator set up run their stored, signed playbook without a new approval; a routine only reads. Gap: multi-factor authentication on approvals is a Complete-plan setting and off by default; without it, an approval accepted in an MCP client prompt shows that the client accepted it, not that a person pressed the key. Gap: approval is a push to the approver's phone, not a passkey bound to the proposal, and GAEZLA does not yet offer separate-approver or freeze rules.
22–23
Each decision records who approved it, over which channel, under which requirement, the multi-factor result, when, and what ran. Evidence for a case is append-only, and the investigation trail is visible live. Gap: approval records are ordinary database rows, deleted with their case; we do not call them immutable. Operator actions are delivered to your monitoring integration when you connect one, and nothing is kept without it.
24–25
Each customer is provisioned with its own worker, database, key-value store and storage buckets. Our sub-processors and DPA are public. Gap: we hold no SOC 2 or ISO 27001 certification and claim none, and we have not yet published a conformance statement against the specification.

Next step

Ask us all 25.

Bring the checklist and your security reviewer to a 30-minute walkthrough, or start a trial and check the answers against your own systems.

Book a walkthroughStart a trial