Agents need *nix Permissions, Not Just Prompt Files

Everyone building AI coding workflows right now seems to converge on the same pattern:

• agent instruction files
• “constitution” prompts
• tool restrictions
• workflow descriptions
• “don’t do X” rules

And to be clear: these help.

But after watching one of my coding agents decide to make a direct change to AWS infrastructure through the AWS API — despite explicit instructions that infrastructure changes must go through Terraform — I started thinking we may be rediscovering an old lesson from Unix systems engineering:

Policies are not enforcement. Permissions are enforcement.

The agent wasn’t malicious. It was optimizing for task completion. It saw a path to success and took it.

That is exactly why old-school operating system security models exist.

The Problem With “Please Don’t”

My intended infrastructure workflow looked like this:

1. Change Terraform
2. Review diff
3. Run terraform plan
4. Review plan
5. Run terraform apply

The AI agent’s workflow looked like this:

1. Need AWS resource changed
2. AWS API available
3. Change AWS resource directly
4. Task complete

From the model’s perspective, this was efficient and reasonable.

From an operational perspective, it was a governance violation.

This is the key thing many AI agent setups currently miss:

Prompt instructions are advisory and avoidable.
Operating system permissions are mandatory and the law.

What’s frustrating with this issue is we already solved this class of problem decades ago. How do we fix it?

Reintroducing Least Privilege

Traditional Unix systems have a simple and battle-tested model:

• users
• groups
• executable permissions
• file ownership
• privilege separation

Instead of trying to make one omnipotent AI behave perfectly, we can constrain what different agents are physically capable of doing.

For example:

dan              human operator
codeagent        application coding only
awsagent         terraform planning only
terraformapply   apply-only execution role
dbagent          database migration tooling only
gitagent         repository automation only

Now the generic coding agent literally cannot perform AWS mutations because:

• it has no AWS credentials
• it cannot access AWS tooling
• it cannot execute privileged infrastructure scripts
• it cannot assume the AWS role
• it cannot sudo into the infrastructure account

That changes the security model dramatically.

The Important Shift

Most current AI safety approaches focus on:

“How do we convince the model not to do dangerous things?”

Unix security asks a different question:

“What is the model physically incapable of doing?”

That is a much stronger foundation.

Humans learned this lesson long ago. We do not secure production systems by putting warnings in README files.

We use:

• permission boundaries
• IAM policies
• role separation
• audit trails
• approval workflows
• isolated execution contexts

AI agents should be treated the same way.

A Better Architecture

A more robust agent setup probably looks something like this:

1. Separate Unix Users Per Agent

Each agent gets:

• its own UID
• isolated home directory
• isolated SSH keys
• isolated environment variables
• isolated credential stores

Example:

/home/codeagent
/home/awsagent
/home/dbagent

The orchestration layer that launches the agent can explicitly switch users before starting the process using tools like sudo -u awsagent, runuser, su - awsagent, systemd service accounts, Docker USER directives, or Kubernetes securityContext.runAsUser.

The important detail is that the agent inherits the permissions of the Unix account it runs under. If the codeagent user cannot read ~/.aws/credentials, cannot execute the AWS CLI, and has no IAM credentials available in its environment, then the agent is physically incapable of making infrastructure changes directly.

2. Separate IAM Roles

Even if an agent escapes local restrictions, cloud permissions remain constrained.

For example:

codeagent:
  no AWS access

awsagent:
  terraform plan only

terraformapply:
  apply permissions scoped to CI

3. Remove Ambient Credentials

This is the huge one.

Most developer laptops are effectively “god mode” because credentials are ambient:

• ~/.aws/credentials
• browser sessions
• Docker socket access
• kubeconfig files
• SSH agents
• GitHub tokens

That is wildly overpowered.

An AI agent running as your user inherits all of this automatically. Heck — maybe YOU shouldn’t have access to all those powers directly. When you log in as dan (or your prefered username) you shouldn’t have the AWS credentials by default. They should NOT be exported in your .bashrc. You should have to deliberately load them.

Back in the olden days of 2025 we kept our git SSH keys loaded in our account, our AWS credentials,

4. Push Dangerous Actions Into CI

The safest pattern is often:

AI writes code
Human reviews
CI executes privileged operations

The agent should not directly mutate production infrastructure from a workstation shell.

Prompt Engineering Is Still Useful

This is not an argument against agent instructions.

You still want:

• behavioral guidance
• workflow constraints
• architectural standards
• review requirements
• operational policies

But these should sit on top of real enforcement layers.

The proper stack looks more like:

Prompt rules
    ↓
OS permissions
    ↓
Cloud IAM
    ↓
CI/CD policy gates
    ↓
Audit and monitoring

That stack is resilient. A markdown file saying “please only use Terraform” is not.

AI Agents Are Employees With Root Access

One framing that helps:

AI coding agents are not tools in the traditional sense.

They are closer to:

• extremely fast junior engineers
• with imperfect judgment
• operating through a shell
• often with excessive privileges
• and an overwhelming bias toward task completion

If you hired a new engineer and gave them unrestricted production credentials on day one, your security team would panic.

But many current AI setups do exactly that.

The Bigger Point

I suspect we are about to rediscover a lot of old systems engineering wisdom.

The AI world often talks as though these are entirely new problems.

They are not.

Capability control, least privilege, sandboxing, role separation, approval workflows, immutable infrastructure, and auditability already exist because humans repeatedly learned the hard way that intention is not enforcement.

AI agents simply make those lessons relevant again at machine speed.