What to write when they ask what an agent is allowed to do

What the row is asking

Reviewers ask what the agent is allowed to do. They want the tools it can call, whether those tools only read or can also change something, and which actions run with no person in front of them. A line that says you handle prompt injection does not answer that.

RIVER, on a page dated 29 July 2026, by Louise Epa, AI Analyst and Research Consultant, and Kevin Fuavao, Chief AI Officer, writes: "We handle prompt injection" is now a line in most AI vendor decks, and on its own it means nothing. The same page says "Do you defend against prompt injection?" gets the honest answer "partly" from everyone. Question 2 on that page: "What can the agent do without a human? Reading is one risk level. Sending an email, changing a record, moving money or deleting a file is another." The same page says an agent's tools and credentials are its blast radius, and that least privilege should come with a permission list. A pull quote next to Kevin Fuavao's name: "When I wire an agent into a client's systems, the first thing I write down is the list of tools it can call and the identity it calls them with. That list is the security review." The same page says "None of that solves prompt injection. Nobody has." That is their sentence. RIVER writes what to make a vendor prove. This is their page, not a founder asking for help.

A comment on r/SaaS, August 21, 2026, from u/rupert_at_work: "I'd scope it around blast radius more than model weirdness. Prompt injection matters, but the real question is: if the model gets tricked, what can it read, write, delete, email, refund, export, etc.?" The same comment names a practical baseline of tenant isolation, least-privilege tool access, no secrets in prompts or logs, rate limits, audit logs, output validation, and human approval on anything expensive or irreversible. Role, company, and headcount are not stated. A different comment from this account is in an earlier note. This one is not. The original poster, u/unlock_access, the same day, asked what the practical scope of security is for an AI app and named prompt injection. They were asking. They did not describe a questionnaire they had received.

A post on r/SaaS, July 10, 2026, from u/Few-Garlic2725: "Prompt guardrails are not access control." The same post says "If an AI agent can read private repos and write public comments, the bug already exists," and asks "Are you giving coding agents repo-wide access, or locking them down per task?" Company and headcount are not stated. The post is about a public incident. It is not a questionnaire they were filling.

A comment on r/SaaS, June 10, 2026, from u/ConfigAgent: "We almost lost a deal because the sheer manual effort required to prove our agent permissions and multi-tenant isolation killed our momentum, and the timeline completely fell apart." Role, company, and headcount are not stated. That sentence is June 10, before the later pages above. No source dated from July 10, 2026 on says a named deal died on a tool name. The original poster, u/Home_United, the same day, says they are working on some AI-powered apps, chatbots and agents, and asks whether deals were delayed or lost. The questions they list include prompt injection risks, agent permissions and oversight, and potential runaway actions. They are asking. They do not describe a form they have in hand. On June 15, 2026, they ask whether people hire a consultant and what they pay. No reply names a fee. A comment on June 11, 2026, from u/g00dsl33pn0w, opens "My impression" and says that if someone asks about prompt injection, data retention, model access, human oversight, or auditability, they are often trying to understand whether there is an existing process behind the answer. That is not a deal they closed. Isolation is a different row, and it already has a page.

Bastion Intelligence, by Josh Spencer, on a page that says Published July 18, 2026, and Updated July 18, 2026, asks "Can any output execute an action without human review?" A separate sample on that page asks how you defend against prompt injection, insecure output handling, and training-data poisoning. Those lines are samples on the page. They are not a quote from a named hospital. The page is a questionnaire for healthcare AI vendors. This is their list, not a founder asking for help. The training question is a different row.

A checklist on r/AskNetsec, May 8, 2026, from u/Ambitious-Load3538, is outside that later window. They write for people who review vendors or internal apps, and ask "what tools the agent can call" and "whether those tools are read-only or mutating," plus evidence that prompt injection cannot directly trigger a high-blast-radius action. Employer is not named. The day before, the same account asks whether AI agent posture is going into security questionnaires yet. That is a question. It is not a report that a named customer sent the list. Do not treat the May post as proof that every form now has the row.

What reviewers accept

Write the tool list only when each name is true. Say what each tool can do: read, write, delete, email, refund, or export. Keep only the verbs that are true.

Say which of those actions a person confirms before they run. Reading is a different level from sending an email, changing a record, or deleting a file. An output that can change something with no person confirming it needs its own sentence, and only when that is true.

A bounded answer names the limit. The agent can only read, or the tools are this list and nothing else. Least privilege with no list is not the answer. Prompt guardrails are not that list.

Write that prompt injection is not a solved line. Do not write that you have solved it. The July 29 page says a deck line about handling prompt injection means nothing on its own, and that the honest answer to the defense question is partly.

If the list is not written, say not yet. If you are still choosing the tools, or which actions wait for a person, say still deciding. Leave the tool names out until you have chosen them.

Have the list written before the form arrives, so the week is not spent proving it from scratch. The June 10 comment is one person who almost lost a deal while proving permissions and isolation. It is not a count. It is not a named deal that died on a tool name after July 10, 2026.

The log the customer can read or export, how soon you tell them about an incident, whether one customer can see another's data, whether customer data trains a model, which model company is on the vendor list, what data each vendor can see, and who on your team can open production are other rows.

An honest gap is a complete answer. The answer that fails is we handle prompt injection, with no list of tools and no sentence for what a person confirms.

What not to write

Do not write we handle prompt injection as the answer.

Do not write least privilege with no list of tools.

Do not write a tool name that is not true.

Do not write that a person confirms an action unless they do.

Do not write that the agent can only read if it can also write, delete, email, or send.

Do not treat a prompt guardrail as the permission on the key.

Do not answer the audit log, isolation, training, the incident clock, what a vendor can see, or who on the team can open production here.

Do not put the permission list on the vendor row. There is no field for it.

Do not invent a tool, an approval rule, a solved prompt-injection line, or a deal that died.

Where this answer lives

Keep these sentences in the questionnaire answer you control.

The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.

You can name the model company as a vendor row once you type it. If the editor already knows that company, a suggestion can offer a location or a public agreement link, and only after you use it.

There is no field for a permission list, an approval rule, or a prompt-injection claim. The page does not fill this row. The product cannot store what the agent is allowed to do.

That suggestion does not write a permission list, an approval rule, or a prompt-injection claim.

If you want the longer notes

What is logged, and whether the customer can read or export that log, is a different row. What to write is in the audit log guide.

Whether one customer's agent can reach another customer's data is a different row from what this agent is allowed to do. What to write is in the customer data isolation guide.

Whether customer data trains a model is a different row from what the agent is allowed to do. What to write is in the customer data training guide.

Naming the model company on the vendor list is a different row from what the agent is allowed to do. What to check is in the AI provider guide.

Who is on the hook when something goes wrong, and how soon you tell the customer, is a different clock. What to write is in the incident notification guide.

Who on your team can open production is a different row from what the agent is allowed to do. What to write is in the access review guide.

What data each vendor can see is a different row from what the agent can read, write, or send. What to write is in the data access guide.