Skip to main content

Why this exists

AI coding agents run with your credentials.

That sentence is the whole argument, and it is worth being concrete about what it means in practice. A single agent on a developer laptop typically has:

  • a cloud identity that can assume other roles
  • MCP servers rooted above the project directory
  • a shell
  • long-lived keys sitting in ~/.aws

None of that is a misconfiguration. It is the default setup that makes agents useful. The problem is that it is also invisible: the agent was installed by a developer, its MCP servers were configured in a dotfile, and nothing in the organisation's existing tooling knows any of it exists.

The three questions​

  • How many agents do we have? Not how many are approved — how many are installed.
  • What can they reach? Not what they were intended to reach.
  • Who owns them? The question that turns a finding into an action.

Most teams cannot answer these. Not because they are careless, but because the information lives on individual workstations and nothing collects it.

Why a local tool​

Agent configuration is local. MCP servers are declared in per-user files and per-project .mcp.json. Credentials sit in the home directory. An agent's real blast radius is a property of the machine it runs on, so the only place to measure it accurately is that machine.

This has a consequence worth stating plainly: a single workstation cannot see the organisation. Correlating agents across machines and accounts is a genuinely different problem, and this tool does not pretend otherwise.

Why enforcement is narrow on purpose​

It would be easy to claim that a local tool "blocks dangerous agent actions". Unveilr Guard blocks actions on paths where it sits authoritatively in the call path — today, the MCP gateway. If an agent shells out directly, the gateway is not in that path and does not see it.

The narrow claim is the honest one, and it is also the more useful one: you can reason about exactly which actions are covered, rather than trusting a promise that quietly has holes in it. Limitations enumerates them.

Why AGPL​

The open-source product is not a demo, a trial, or an installer for something else. It is designed to be genuinely useful with no account, and capability is not removed from it to create commercial value — the split is organisational scope. See Open source vs Enterprise.