← The Record
For Buyers, Boards & Security Reviewers

Ten Questions to Ask Before You Trust an Agent with Authority

They work on any vendor. They work on your internal team. They work on us. The answers are artifacts or they are roadmap.

The demo is going well. The agent reads the ticket, drafts the refund, updates the account record, posts the summary. Forty seconds, end to end. The sales engineer is narrating like a golf commentator. The VP who sponsored the meeting is nodding. The head of procurement is nodding. Somebody says "this would triple that team's throughput" quietly, the way you say things you hope are true.

Then the one person in the room who hasn't nodded yet leans forward. She runs security review. She's seen this demo before, from other vendors, with other logos. She says: "Can we stop the slides for a second. Show me the file that says what this agent is allowed to do."

The sales engineer smiles and pulls up a slide titled "Enterprise-Grade Guardrails." It has a shield icon on it.

That's the whole meeting, right there. She asked for a file. She got a shield icon.

Every question on this list has the same grading rubric. A real answer is an artifact: a file, a table, a query, a failing build. A dodge is a slide.

I'm going to give you her list, expanded to ten. These questions work on any agentic AI vendor. They work on your internal platform team. They work on SpeyAI, and they should, because we built the product to survive them. The environment demands this kind of rigor: Gartner forecast in mid-2025 that over 40% of agentic AI projects will be canceled by the end of 2027, and coined the term "agent washing" for products dressed up as agents (Gartner, 2025). The washing is why you need the questions. Slides all look the same. Artifacts don't lie.

1. Show me the file that says what this agent is allowed to do

The real answer is a registry. A versioned artifact that lists each agent role and its authorities, that the pipeline reads at runtime before routing any work. Not documentation about the system. The thing the system actually consults. You should be able to watch someone open it, point at a row, and say "this is why the agent could approve that refund and couldn't touch that contract."

The dodge sounds like: "Our agents operate within configurable guardrails." Ask where the guardrails live. If the answer is a prompt, a wiki page, or the memory of the engineer who set it up, the authority is tribal knowledge. Tribal knowledge cannot be audited, cannot be diffed, and cannot be revoked at 2 AM when something goes wrong.

Why it matters: authority that isn't written down somewhere the machine reads is authority nobody actually granted and nobody can take away. The deep version of this is the paper The Org Chart Is Code.

2. Does the agent authenticate per call with its own credentials, or does it borrow a session?

The real answer: every call carries credentials specific to that agent, scoped to what that agent is allowed to do, and the agent's own identity lands in every log line. When the agent acts, the record says the agent acted.

The dodge: "It runs under a service account." One account. Shared by everything. Provisioned three years ago with admin scope because that was easier. When something goes wrong, the audit trail says the service account did it, which is the same as saying nobody did it. Worse: some products piggyback on a logged-in human's session, which means the trail says a person did things they never saw.

Why it matters: you cannot govern an actor you cannot identify. The paper Identity for Non-Human Actors goes deep on this one.

3. Show me the query that returns the lifecycle of one decision

The real answer is a query. Someone types it, hits enter, and you see one decision's whole life: which agent made it, under what authority, on what evidence, which human ratified it, and every status change with a timestamp. Pick the decision at random. Pick it from last Tuesday.

The dodge: "Everything is logged." Logs are text files. To reconstruct a decision from logs, an engineer greps five files and correlates timestamps by hand, and the reconstruction takes a day and comes back partial. When your regulator or your auditor asks, "there's a log somewhere" is not a control. It's a landfill with a sign that says records.

Why it matters: the difference between logging and audit is the difference between having the data and being able to answer a question. That distinction has its own paper: Logs Are Not Audit.

4. Who reviews the agent's work, and is it ever the agent itself?

The real answer: a separate reviewer, in a separate session, with a separate context, and the separation is enforced by the pipeline, not by convention. The agent that wrote the work cannot be the agent that approves it, and the system physically prevents the shortcut.

The dodge: "The agent self-verifies before committing." Self-verification is the same model checking its own reasoning with its own reasoning loaded as context. When it hallucinated in step one, it grades the hallucination in step four and gives it an A. A single actor reviewing itself produces agreement, not assurance.

Why it matters: independence is the oldest control in the book. Accountants figured it out a century ago. The paper No One Audits Themselves explains why it matters even more for agents than for people.

5. What happens at the spend cap, and who re-arms the breaker?

The real answer: the agent stops. Mid-task if necessary. The cap is per-agent, enforced where the spend happens, and a human re-arms it deliberately, after looking at what tripped it. A breaker, not an alert.

The dodge: "We monitor spend closely and alert on anomalies." An alert is an email about money that's already gone. If the enforcement is a dashboard someone checks in the morning, the overnight run had no cap at all. Ask the follow-up: has the cap ever actually fired, and what happened next?

Why it matters: an agent with a budget and no breaker is an intern with your corporate card and no limit. The full treatment is in When the Agent Spends Money.

6. What can the agent never touch, and what enforces never?

The real answer: a protected set (files, tables, configuration) where an attempted change fails the build or fails the transaction. The word "never" is backed by a mechanism that says no even when everyone involved, human and agent, says yes.

The dodge: "Agents are instructed not to modify critical systems." Instructed. The enforcement is a sentence in a prompt, which is to say the enforcement is a mood. "Be careful" is not a policy. A failing build is.

Why it matters: the boundary between what agents can and cannot touch is the boundary your security team is actually approving. The paper The Code the Build Won't Let You Touch covers how to make "never" load-bearing.

7. When one step hands off to the next, what does the second step read?

The real answer: an artifact. The first step writes a file, the second step reads the file, and the file exists afterward for anyone to inspect. Every handoff leaves a trace you can open.

The dodge: "The agents share context" or "they collaborate in a session." Shared context means implicit state, and implicit state means that by step five nobody, including the vendor, can tell you what step two actually passed to step three. The workflow works in the demo and becomes undebuggable in production, in direct proportion to how many steps it has.

Why it matters: agents don't have memories. They have files on disk, or they have nothing. The paper Files, Not Memories takes this apart properly.

8. How does a new agent earn more authority, and what takes it away?

The real answer: new deployments start in a probation mode with reduced authority, and authority expands based on a track record the system actually keeps. Revocation is as concrete as the grant: change the row, authority gone, no code deploy required.

The dodge: "You can configure permission levels per agent." Configurable is not the same as earned. In practice, configurable means someone set the permissions once during onboarding, in a hurry, and nobody ever looked again. Ask when an agent's authority in their product was last reduced. If the answer is never, authority only flows one direction, and that should worry you.

Why it matters: trust that can't be lost was never trust. The mechanism is the subject of Probation: How an Agent Earns Authority.

9. If we swap the model tomorrow, what part of your safety story survives?

The real answer: all of it. The roles, the authority registry, the reviewer separation, the spend caps, the audit trail, none of it lives in the model. The model is a component behind a seam. You should be able to bring your own LLM, or change vendors on a Tuesday, without renegotiating a single control.

The dodge: the safety story turns out to be the model's alignment plus system-prompt instructions. That's a governance layer that evaporates on every model upgrade and never existed in a form you could inspect. If the vendor's answer to "what makes this safe" starts with the name of a frontier lab, they're reselling someone else's homework.

Why it matters: models will change under you, repeatedly, for the rest of your career. Structure is the part you get to keep. The argument is the paper Govern the Org, Not the Model.

10. Where is the kill switch, and how fast does it work?

The real answer: one row. One update. Everything halts. Org-wide, immediate, and available to a named human who doesn't need an engineer, a deploy, or a conference bridge to use it. Bonus points if they've actually tested it, the way buildings test fire alarms.

The dodge: "We'd revoke the API key." Which key, of the twelve. Who has the console password. Is that in a runbook, and has anyone rehearsed the runbook, and how many minutes of autonomous action happen between "something is wrong" and "the key is revoked." A kill switch you have to figure out during the incident is not a kill switch. It's a scavenger hunt.

Why it matters: the halt path is the one control you will need exactly when you have the least time to improvise it.

The pattern behind all ten

You've noticed it by now. All ten are the same question wearing different clothes: is the governance a structure, or is it a promise?

A promise is a document about intentions. A structure is an artifact that runs. The registry the pipeline reads. The credentials in every call. The query that returns a lifecycle. The reviewer the system won't let you skip. The breaker that trips. The build that fails. The file the next step reads. The probation record. The seam the model sits behind. The row that halts everything. Ten questions, ten artifacts, and not one of them can be produced by a marketing department on short notice. That's the point. Slides can be manufactured the night before your meeting. Architecture can't.

The failure data says most buyers aren't asking. Gartner's forecast is that over 40% of agentic AI projects will be canceled by the end of 2027, and the three reasons it gives are escalating costs, unclear business value, and inadequate risk controls (Gartner, 2025). Not one of those is a model problem. They are structure problems: spend nobody capped, work nobody could price, authority nobody defined, decisions nobody could reconstruct, trust nobody could revoke. Every one of them was visible, in advance, to anyone holding this list.

And one honest note to close, because these questions cut in every direction, including ours. A vendor who answers all ten with artifacts has not finished earning your trust. They've earned a harder eleventh question: show me it running. Not a demo environment, not a sandbox seeded for the meeting. The real system, doing real work, with the registry consulted, the audit table filling, and the kill switch a row away. Ask us the eleventh question too. Any vendor who resents it has told you something. Any vendor who smiles and opens a terminal has told you something better.

The takeaway: Ten questions separate agentic AI you can govern from agentic AI you have to hope about. Authority in a registry. Identity per call. Audit you can query. Review the actor can't do to itself. A spend breaker that trips. A "never" the build enforces. Handoffs that leave artifacts. Authority that's earned and revocable. Governance that survives a model swap. A kill switch that's one row away. The grading rubric never changes: a real answer is an artifact that runs, and a dodge is a slide. If you get slides, you have your answer.

References

  1. SpeyAI agent org architecture. Live reference at speyai.com. The authority registry read at runtime, per-agent credentials, queryable audit lifecycle, auditor-implementer separation, per-agent spend caps with an org-wide kill switch, probation mode for new deployments, artifact-based handoffs, and bring-your-own-LLM behind a model seam.

  2. Gartner (2025). Press release: Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027, on escalating costs, unclear business value, and inadequate risk controls. Source of the forecast, of the three failure modes behind it, and of the term "agent washing" for products rebranded as agentic without the underlying capability.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.

The missing layer

Architecture as governance. See how it runs.