Ambient authority
Also called: ambient permissions · inherited authority
When you launch a program on macOS, Linux or Windows, it receives your identity. Not a subset chosen for the task — all of it. Your user ID, your home directory, your network position, your mounted volumes, your keychain access. Nothing granted the program those things; it simply was not prevented from having them.
That is ambient authority: power that is in the air around a process, available for the taking, unrelated to what the process was actually for.
Why the term matters now
Ambient authority is not new and not a bug. It is how every mainstream operating system
works, and it was a reasonable trade. Programs were written by people, did what their
source said, and if a text editor started reading ~/.ssh that was either a bug or a
crime — and in both cases somebody could eventually find out.
Two things changed with AI agents.
The first is that the program’s behaviour is no longer in its source. An agent’s next action is generated at runtime from a model, a prompt and whatever it read a moment ago. You cannot audit that in advance, so the historical mitigation — inspect the program, then trust it — has nothing to inspect.
The second is that the program’s input is attacker-controlled. Agents read issues, web pages, dependency documentation and tool output. Any of those can carry instructions. An agent holding ambient authority and reading untrusted text is a confused deputy waiting for a prompt.
What it looks like in practice
An agent launched in ~/Projects/app can read ~/.ssh/id_ed25519. Not because of a
misconfiguration — because you can, and it is you. File permissions cannot help: the
permission bits say the owner may read the file, and the agent is running as the owner.
The same applies to your AWS credentials, your browser’s cookie database, every other repository on the disk, the NAS you have mounted, and any host your machine can route to.
What replaces it
The alternative is authority that is granted rather than inherited: the process starts with nothing and receives specific, narrow permissions for specific purposes. That is the core idea behind capability-based security, and the practical version of it for AI processes is AI containment — a boundary outside the process that decides what it can reach, with deny-by-default as the starting position and explicit human grants as the only way to widen it.
The removal has to be the first move. Adding narrow capability to a process that still holds ambient authority changes nothing, because the ambient path is still there.