Run your own backend

Who should be able to touch production?

The short version: default to least privilege - avoid broad standing access to production. Scope and time-box human access to the task. Give automation and AI agents the narrowest practical scope, and choose approval controls that fit the change and deployment mode. Keep selected, reviewable records where operationally appropriate, so “who can touch prod” remains a deliberate question rather than “everyone, with root.”

On this page

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 - reviewable, 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.

Use the AI-agent blast-radius checker to review access scope and the command risk checker to examine individual commands. Configure approval controls separately in the systems that execute those actions.

How Infraveil handles this

Scoped actions within the backend operating workflow

Infraveil combines scoped managed actions with the operating workflow for your backend: deploy, supervise, check health, apply gateway traffic policy, and recover services on your servers. Choose manual approval when a person must review each release, exact-hash allowlisting for matching releases, or automatic approval for unattended delivery. Keep direct host and database access separately controlled; unmanaged paths remain your responsibility.

Customer-configured scopes for documented managed paths
Use manual approval where a person must review each managed release
A selected operational 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 selected operational log of what they did (who did). Review the inventory regularly to remove unused access, and keep the trail trustworthy for after an incident.