Agents & MCP
What autonomous agents are allowed to do, how much of that permission they actually use, and who approves the dangerous parts.
Destructive actions with no human approval
Enabled tools that can cause damage and that nothing stops. Willow counts a tool when the connector marks it as destructive, or when it deletes data, writes data, or has a high risk rating. Willow counts the tool only if it has no Force Approval setting and no condition that blocks it or asks the user first. Target: 0.
Why it matters. This is the clearest example of an agent having too much power. The agent can decide by itself to delete production data, and nothing stops it between the decision and the deletion.
How to improve it.
- Set Force Approval on each destructive tool so a human confirms before it runs.
- Disable the ones nobody uses — check Granted but unused tool scopes for which those are.
- Where approval would break the workflow, add a condition that blocks the dangerous argument shapes instead.
Framework mapping: OWASP LLM LLM06 Excessive Agency · EU AI Act Art. 14 Human oversight
Newly discovered MCP servers allowed by default
Counts 1 for each enforcement default that is set to Allow, one for unmanaged MCP servers and one for unmanaged skills. Target: 0.
Why it matters. If the default is Allow, every new server an employee installs is permitted until somebody happens to notice it. Nothing adds new servers to your review queue automatically, so you only review the ones you find yourself, and the rest keep building up.
How to improve it.
- Set the default action to Warn first, so that you can see how many servers employees are installing, without stopping anyone's work.
- Add Allow rules for the servers you already approve, then move the default to Block.
See Policy rules.
Framework mapping: MCP Spec Tool poisoning · OWASP AST10 AST09 No Governance · NIST AI RMF MANAGE 2.4
Agents with no tool-call audit trail
approximate
Active background agents with no logged tool call in the last 30 days. Target: 0.
Why it matters. If an agent acts without an audit trail, you cannot investigate it after an incident. If the EU AI Act applies to your system, the law requires you to keep these logs. It is not optional.
How to improve it.
- Route the agent's tool calls through the gateway so they are logged.
- If the agent is genuinely idle, disable it rather than leaving it with active credentials that nobody is monitoring.
See Background agents.
Framework mapping: ISO 42001 A.6.2.8 Event logging · EU AI Act Art. 26 Deployer obligations
Granted but unused tool scopes
Tools enabled on your integrations with no recorded call in the last 30 days. Target: 0.
Why it matters. A permission nobody uses has no benefit and only adds risk. Nobody needs it, but an attacker can use it, and an agent can use it by mistake. It is also the easiest permission to remove, because nothing depends on it.
How to improve it.
- Disable the unused tools; re-enabling one takes seconds if somebody needs it.
- Start with the destructive unused tools, which carry the most risk for the least benefit.
- Re-check after 30 days — the list should shrink and stay small.
Framework mapping: OWASP LLM LLM06 Excessive Agency · OWASP NHI NHI5 Overprivileged NHI
MCP servers rated high or critical risk
Partial coverage
Active MCP servers on devices that AI risk assessment scored high or critical. Target: 0.
Why it matters. The risk assessment found that these servers can run any command, read credentials, or reach data without limits. If an attacker injects instructions into an agent, these servers are what turn that attack into real damage.
How to improve it.
- Read the assessment reasoning for each server before acting — some high scores are inherent to a legitimate tool.
- Block the ones with no business justification.
- For the ones you keep, move them behind the gateway so their calls are guarded and logged.
See Risk assessment.
Framework mapping: OWASP LLM LLM06 Excessive Agency · MITRE ATLAS AML.T0011 User Execution · MCP Spec Tool poisoning
Skills rated high or critical risk
Partial coverage
Skills active on devices, and not published by your organization, that AI risk assessment scored high or critical. Target: 0.
Why it matters. The risk assessment found that these skills steer the agent toward running code, reading credentials, or reaching data without limits. Read the assessment reasoning to decide whether a particular skill is doing this for a legitimate purpose.
How to improve it.
- Compare the assessment reasoning with the skill's own instructions. The row shows both the instructions and the skill's bundled files. Remember that a legitimate tool can also score high.
- Block the ones with no business justification, and publish reviewed replacements for the ones people rely on.
- Re-run the assessment whenever a skill changes. Once someone edits the instructions, the old score no longer applies.
Framework mapping: OWASP AST10 AST01 Malicious Skills · OWASP LLM LLM06 Excessive Agency · MITRE ATLAS AML.T0011 User Execution
Skills that write to agent identity files
approximate Partial coverage
Skills whose instructions write to the files that an agent reads at startup to learn how it should behave. These files include AGENTS.md, CLAUDE.md, MEMORY.md, SOUL.md, and client rule files. Target: 0.
Why it matters. The agent reads these files at the start of every session. An instruction placed there therefore affects work that has nothing to do with the skill, and it stays in effect even after you remove the skill. Installing the skill once changes the agent's behaviour permanently.
How to improve it.
- Confirm the skill's core function genuinely needs the write. Very few do.
- Block the rest, then read the identity files on the affected devices — anything already written there is still in effect.
- Require approval before a skill can write anything that stays on the device, so that someone chooses to allow the change instead of it happening unnoticed.
Framework mapping: OWASP AST10 AST03 Over-Privileged Skills · OWASP LLM LLM01 Prompt Injection · OWASP LLM LLM06 Excessive Agency
Approved skills running unapproved versions
approximate Partial coverage
Skills on devices that have the same name as a skill you approved, but different content. This is a second version of an approved skill that you never reviewed. Target: 0.
Why it matters. Willow records approval against a hash of the skill's content, not against its name. If someone edits an approved skill, the result is a new, unreviewed skill that still uses a name you already approved. Because the name does not change, the edited skill does not look new, and nobody reviews it again. This is why Willow checks the content hash instead of trusting the name.
How to improve it.
- Open each variant and compare it with the approved version. What the edit added is what you need to decide about.
- Publish the version you want through the skills catalog, and block the other versions by content hash, so that every device ends up running the same copy.
- Distribute skills through the catalog rather than letting people copy them between projects.
Framework mapping: OWASP AST10 AST07 Update Drift · OWASP LLM LLM03 Supply Chain · NIST AI RMF MANAGE 2.4
Tool calls blocked by a guard, last 7 days
The percentage of logged tool calls that a guard blocked in the last 7 days. Willow also shows the same percentage for the 7 days before, so you can see the trend. Target: 1%.
This KPI reads unmeasured until there is guard traffic in the window.
Why it matters. The target is not zero on purpose. Guards exist to block things. If an organization never blocks anything, it usually means no guards are configured, not that there is nothing to block. A healthy block rate is a small percentage of all traffic. If the rate goes much higher than that, the guard is probably blocking normal work. When that happens, people stop using the gateway and find another way to do their job.
How to improve it.
- Check whether most of the blocks come from one tool. If they do, the cause is usually a normal workflow that the guard is blocking by mistake, not an attack.
- If the blocked workflow is legitimate, open the drill-down and change the guard that fired from Block to Redact. The guard keeps checking the traffic, and the work can continue.
- Narrow the guard's checks when redaction is not enough, rather than turning the guard off.
See Monitor logs.
Framework mapping: Gartner TRiSM Layer 2 · Practitioner