Ten questions a risk team should ask before agents touch production

Most agent governance conversations start with a demo and end with a vague sense of reassurance. A more useful conversation starts with questions a risk or security team can ask of any vendor, including us, and can actually get a specific answer to rather than a reassuring one. Here are ten, in the order we think they should be asked.

1. Can you prove which agent took this action, without trusting the agent’s own word for it?

The baseline question. The answer should describe a cryptographic proof a third party can check, not a log line the agent itself wrote, which an agent (or whoever compromised it) can write however it likes. If the answer relies on the acting system’s own self-reported identity, that is not proof, it is an unverified claim with a timestamp attached.

2. Is permission decided per tool action, or per agent at provisioning time?

A fixed permission set assigned when an agent is set up drifts from what that agent actually does over time, and does not account for an agent that delegates work to another agent. Ask specifically whether a reviewing agent can be prevented from merging, as a distinct action from reviewing, and whether that is enforced at the moment of the tool call or only as a convention in a prompt.

3. If delegation exists, can a delegated credential ever hold more authority than the one that created it?

This should be answerable with a mechanism, not a policy. Ask what actually stops a worker agent, spun up by an orchestrator, from being minted with broader access than its orchestrator held. “We tell people not to do that” is not a control.

4. What happens when revocation and verification disagree, because the verifier could not reach the revocation record?

The honest answer names a specific behaviour: refuse, by default, when the revocation check cannot be completed. If the answer is “it proceeds, and we log it,” that is a fail-open control wearing a revocation feature’s name.

5. How long does a credential remain valid if nobody’s revocation check ever catches it?

This is the question that bounds your actual worst case. A system that cannot answer “revoked everywhere, instantly” (nobody honestly can) should still be able to answer “the longest this credential can possibly do damage for, if revocation never reaches it, is this many minutes or hours.” If credentials are long-lived or unbounded, that number is large regardless of how good revocation is elsewhere.

6. Where does the audit record live, and who can alter it after the fact?

An audit trail that lives in the same database the acting system writes to, with the same write access, is not independent of the thing it is supposed to be checking. Ask specifically whether the record is tamper-evident, meaning an alteration after the fact is detectable, not merely that it is “logged.”

7. Does the audit record cover every action, or only the ones someone remembered to instrument?

A system that logs the actions it was explicitly told to log, rather than every action that passed through its enforcement point by construction, has a coverage gap that is invisible until an incident goes looking for a record that was never written. Ask what mechanically guarantees coverage, not what the intention was.

8. If this has to run somewhere other than the vendor’s own infrastructure, what is actually true today, versus on the roadmap?

Push for a specific, dated answer: hosted now, in our own cloud account being built, on the roadmap but not started, or not planned. Treat “we support flexible deployment” without a specific answer to that question as a sign the honest answer is somewhere unfavourable in that list.

9. What is the fallback when the permission check itself is unavailable, slow, or errors?

A permission check that fails open when it cannot complete, allowing the action through rather than blocking it, has quietly become optional under exactly the conditions, load, an outage, a misconfiguration, when it matters most. Ask what the system does in that specific failure case, not what it does when everything is working.

10. Can an outside party verify any of this independently, or does everything route back through the vendor?

A credential, a signature, or a delegation chain that can only be checked by calling the vendor’s own service is not independent verification, it is a trust relationship with extra steps. Ask specifically whether a third party, holding only published public material, could check the claim themselves, with no account and no call to anyone.

Why these ten, and not a longer list

This list leaves out a great deal that a full security review would eventually cover: network boundaries, key management operational practice, incident response process, and more. It is deliberately narrower than that, focused on the questions specific to letting an autonomous agent, rather than a human operator, take actions against production. Those are the questions that are easiest to leave unasked in a demo, because a demo is built to show the system working, not to show what happens at the edges where it does not.

If you are operating in a context where an EU regulatory framework applies to how you govern AI systems, it is worth noting that Regulation (EU) 2024/1689, the EU AI Act (Official Journal of the European Union, 12 July 2024), entered into force on 1 August 2024, with its prohibitions on certain practices applying from 2 February 2025, governance obligations for general-purpose AI models from 2 August 2025, and the bulk of its remaining obligations, including those for high-risk AI systems, applying from 2 August 2026. Several of the questions above, who can prove what an agent did, whether a decision is traceable, and how oversight is maintained, sit close to the kind of record-keeping and human-oversight expectations that framework describes for higher-risk uses. Whether any specific deployment counts as high-risk under that regulation is a legal question for your own counsel, not something a vendor can answer for you, but the shape of the questions above is a reasonable starting point for that conversation either way.

Ask these ten of any vendor you are evaluating, including us. The useful answer to most of them, honestly given, is not “yes” across the board. It is a specific account of what is true today, what is partial, and what is not built yet, which is exactly the kind of answer a demo alone cannot give you.