Every conversation about AI coding assistant security starts in the wrong place. It
starts with the model — is it trustworthy, was it trained on our code, can it be
jailbroken. Those are real questions. They are not the ones that decide whether an
agent can delete your .env file this afternoon.
That is decided by configuration. An agent is a process with a shell, a filesystem, a network, and a set of connected tools. What it can do to a laptop is a function of five settings, all of which ship with defaults chosen for a good demo rather than a fleet.
1. Auto-run
Every major assistant has a mode that stops asking. Cursor calls it auto-run, Claude Code has permission modes, and most agent frameworks have some equivalent flag that turns "may I run this command?" into a command that has already run.
Developers turn it on for the obvious reason: the approval prompt is exhausting, and
after the twentieth npm test it stops carrying information. The problem is that the
prompt is also the only thing standing between a prompt injection and a shell. Once
auto-run is on, the difference between a helpful agent and a hostile one is entirely
a question of what text it happened to read.
The useful policy is rarely "off". It is "off for anything that writes, installs, or reaches the network", which most tools can express and almost nobody configures.
2. Workspace trust
IDEs have carried a workspace-trust prompt for years, because opening a folder can execute code from that folder — tasks, extensions recommendations, language server configuration. Agents inherit all of it and add more: a repo can now ship an instructions file that the assistant reads as guidance.
Disabling workspace trust makes cloning an unfamiliar repository an execution event. People disable it because the prompt fires on every project, including their own.
3. Privacy and telemetry controls
Separate from whether an agent is dangerous is the question of where your code goes. Assistants differ enormously in what leaves the machine by default, and in whether "privacy mode" covers prompts, completions, file contents, or only usage analytics.
This is the setting most likely to be wrong for a compliance reason rather than a security one, and the one most likely to have been set correctly once, on one laptop, in a meeting nobody wrote down.
4. Which MCP servers are allowed to connect
MCP is where the blast radius stops being local. An MCP server is a third-party process that the agent will call on its own initiative, with whatever credentials you handed it. Most are installed with a single line in a config file, from a registry that does not vet anything, by a developer who wanted to try something.
There is no allowlist by default. There is no default at all — every server anyone adds is connected, and the only inventory is the union of everyone's config files.
5. What the agent may touch on disk
The last one is the least discussed and the easiest to get right: whether an agent can read and write dotfiles, credentials directories, and anything outside the project it was invited into.
~/.aws/credentials, ~/.ssh/, .env, the shell profile that runs on every new
terminal — an agent with no restriction on these has, in practice, the same access
as the person sitting at the keyboard. That is the intended design. It is also the
part of the design that assumes everything the agent reads is benign.
The reason this is hard
None of these five are obscure. Every one is documented, and a careful developer can set all of them correctly in about ten minutes.
The difficulty is that there is no they. These settings live in per-user config files, on individual laptops, in five different formats, changed by whoever last followed a setup blog post. A security team asking "is auto-run enabled anywhere in this company?" has no way to answer it, and neither does the developer sitting two desks away.
Which is the actual gap. Not that the settings are wrong — that nobody can see them.
Armor1 discovers the configuration of every AI coding assistant across a fleet, scores every connected MCP server, and enforces policy on what agents do at runtime. It is agentless: no code scanner, and no change to how developers work.