Ask eight questions about agent tool permissions in any security demo: what each agent can reach, which identity it uses, who approves new tools, how access is revoked, what is logged, how changes are noticed, what happens on failure and what the default is. Ask them live, on your own example.
Why permissions are the center
Agents act. A model that only answers questions is limited by what it says. An agent with tools is limited by what those tools can do. That is why the MCP specification says there should always be a human in the loop who can deny tool invocations, and why servers must apply access controls.
OWASP's LLM Top 10 names excessive agency as its own risk. In plain terms, an agent with more access than the task needs turns a small mistake into a large one.
The eight questions
- What can this agent reach? Ask the presenter to show one agent and list its tools, folders and accounts. A list is better than an adjective.
- Which identity does it use? A shared service account hides which agent acted. A distinct identity per agent makes records meaningful.
- Who approved this tool? Ask for the name and date of the approval, not a policy statement.
- How is access removed? Ask them to revoke one agent live. Count the steps and how long until it takes effect.
- What gets logged? Ask for the log line for one tool call. Look for agent, tool, input summary, outcome and time.
- How do we notice a change? If a tool's description or scope changes after approval, does anything tell you?
- What happens on failure? If the policy service is down, does the agent keep acting or stop? Either may be right, but you should know which.
- What is the default? New agents and new tools should start with the least access. Ask what a fresh install allows.
Reading the answers
| Answer | What it suggests |
|---|---|
| Shows it live on your example | Capability is real and current |
| Shows slides or a canned run | Ask again with your example |
| "It depends on configuration" | Ask for the default and how to see the setting |
| "We do not do that, use another system" | Fair, note it as a gap |
The fourth row is a good answer more often than buyers expect. Note the gap and decide who closes it.
Linking to your own controls
The questions line up with controls you probably already have for people: unique accounts, approval workflows, access reviews and audit logs. The new part is applying them to non human actors. Our guide on the agent permission matrix by environment shows how to decide scope, and AI agent identity evaluation for buyers goes deeper on identity.
What to bring
Print the eight questions. Add your own example agent, ideally one that is already planned. Ask the same questions of every vendor, in the same order, and write the answers down in one table. Differences between vendors then show up as differences in rows, not in impressions.
Safeguard provides agent identity, policies, gates and guardrails, and MCP Guardrail, among other capabilities. As with others, we expect you to ask these eight questions of us too.
Quick check
Do these questions apply to coding assistants too?
Yes. A coding assistant that can run commands or edit files is an agent in this sense. Scope and approval matter as much as for a service agent.
Is human approval of every action realistic?
Not at volume. Approve by category and risk, and reserve per action approval for sensitive or irreversible operations.
Sources
- Model Context Protocol, Tools specification (2025-06-18)
- OWASP Top 10 for LLM and GenAI Apps 2025, LLM06 Excessive Agency
Last reviewed: 19 October 2026.