Run your own backend

Who should be able to touch production?

The short version: default to least privilege - nobody and nothing gets broad standing access to production. Humans get access that is scoped to the task, time-boxed, and audited. Automation and AI agents get the narrowest possible scope, with a human gate in front of anything destructive. And everything is recorded - so “who can touch prod” has a short, deliberate answer instead of “everyone, with root.”

The principles

Least privilege

Every human, service, and agent gets only what its task needs - so one compromise is contained, not catastrophic.

No standing access

Grant access just-in-time for a task and a limited time, then revoke - not permanent admin for everyone.

Human gate for destructive actions

Anything irreversible - especially from an AI agent - waits for a person to approve. The actor proposes; a human commits.

Audit everything

Record who could access what, and what they actually did - tamper-evident, so it is trustworthy after an incident.

Who and what needs what

  • Humans - scoped, just-in-time, audited access for the task at hand, not standing root. Most day-to-day work needs read, not write.
  • CI/CD - a deploy identity scoped to deploying, with no access to data it does not need. A leaked pipeline token should not be a leaked database.
  • Services - per-service credentials, each scoped to its own resources, so one service cannot reach another's secrets.
  • AI agents - the narrowest scope of all, with reversible actions automatic and destructive ones gated behind a human. Speed without an unbounded blast radius.
The new risk

The AI-agent blast radius

An AI agent is fast, literal, and tireless - which is exactly why broad production access is so dangerous. A single ambiguous instruction can become a dropped table or a wiped bucket in seconds, with no pause to reconsider. The fix is not to lock agents out, it is to scope them tightly and put a human-approval gate in front of anything destructive or irreversible: the agent proposes the action, a person reviews the blast radius, and only then does it run.

See exactly what an agent could do with the blast-radius checker, classify individual commands with the command risk checker, and generate a guard config with the agent guard config.

How Infraveil handles this

Gated, scoped, recorded - by default

This is exactly what Infraveil is for. On your own servers, it sits between your tools - including AI agents - and your backend, so every action is scoped to least privilege, destructive actions are gated behind your approval, and everything is written to a tamper-evident audit trail. The agent or the pipeline can move fast on what is safe and reversible, while “who can touch prod, and who did” stays a deliberate, answerable question.

Every action scoped to least privilege, on infrastructure you own
Destructive actions gated behind your approval - the agent proposes, you commit
A tamper-evident record of who could, and who did

Frequently asked questions

What does least privilege actually mean?

Every person, service, and agent gets only the access its task requires. A deploy job deploys, it does not read the customer database; an agent that opens PRs does not drop tables. Scoping to the task means a single leaked token or confused agent is contained, not catastrophic.

Should an AI agent have production access at all?

Only narrowly, and never unattended for destructive actions. Give it the smallest scope for its job, make reversible actions automatic, and gate anything destructive behind human approval - the agent proposes, a person approves. Speed without the blast radius.

What is just-in-time (JIT) access?

Access granted for a specific task and a limited time, then revoked - instead of standing permissions forever. It shrinks the window in which broad access exists, which is the thing attackers and accidents exploit.

How do I audit who can touch production?

Keep an inventory of who and what has access at what scope (who could), and a tamper-evident log of what they did (who did). Review the inventory regularly to remove unused access, and keep the trail trustworthy for after an incident.