Feedback request: MCP safety audit taxonomy for agent workspaces

[godhiraj-code]

Hi MCP Registry maintainers, I am validating a local first safety audit format for agent workspaces that use MCP servers.

I am not opening this as a bug report. I am looking for taxonomy feedback from people working near MCP discovery, metadata, and server capability surfaces.

The report maps risks like exposed server/tool surfaces, write/delete/admin capabilities, broad filesystem reach, secrets in reachable directories, missing approval gates, and incident postmortem readiness.

Question:

a) What MCP-specific risk category would you expect this kind of report to catch that normal secret scanners miss?

b) Should server metadata include clearer capability/blast-radius signals for write/delete/admin tools?

c) Would this report format be useful before teams scale MCP usage across agent clients?

If this is not the right discussion area, happy to move it to the right place.

Many Thanks
Best Regards
Dhiraj

[vladimirrott]

@godhiraj-code on (a), the category ordinary scanners miss: a guard inspects the command string, then bash rewrites it before it runs. GuardFall got past the guards of 10 of 11 open-source agents using old tricks like quote removal and $IFS. A grep-style check cannot catch that, because the string it inspected is not the string that executes.

On (b), yes, and blast radius is the right axis. We publish per-action risk level, whether human approval is required, and whether rollback exists, generated from the code so the table cannot drift: https://github.com/lacs-project/sysknife/blob/main/docs/action-reference.md

On (c), the thing I would want before scaling is a straight answer to "which tools can mutate state with no human in the loop", which is close to your missing-approval-gates category.

[godhiraj-code]

Many thanks, this is useful.

Would you group shell expansion, wrappers, and delegated subprocesses under one execution-path category, or model them separately?

[vladimirrott]

@godhiraj-code separately, and your third category earned its place by finding a bug in ours.

Shell expansion and wrappers are both "the string you inspected is not what executed", and both are statically checkable: enumerate the interpolation sites, confirm each parameter has a validator. The strongest pattern we use is passing values as positional args (key=$1) so nothing the caller supplies is ever parsed as syntax.

Delegated subprocesses are different in kind, because they cannot be eliminated: apt and rpm-ostree have to run maintainer scripts. Checking ours against your question, our action timeout kills the direct child, which is sudo, so the privileged work survives it, and the daemon then fires an automatic rollback against a transaction still in flight. Filed as lacs-project/sysknife#140.

Prevention versus containment, different evidence, so I would keep them separate.