PATTERN Cited by 1 source

RBAC + JIT as agent safety net¶

Intent¶

When the safety net for correctness shifts away from manual code review (because agents are writing the code), access-control primitives become the remaining enforcement layer for who — and what — can write to production. Use Role-Based Access Control (RBAC) + Just-In-Time (JIT) access to limit blast radius independent of whether the actor is a human or an agent.

Canonical articulation — Atlassian Fireworks, 2026-04-24:

"If you're not hand-writing code, your safety net shifts: CI/CD pipelines (automated quality gate), Sharding (limit the blast radius of any single change), RBAC / JIT access (control who — and what — can write), Progressive rollouts & canary deploys across multiple clusters, AI-written e2e tests (primary validation harness)." (Source: sources/2026-04-24-atlassian-rovo-dev-driven-development)

What it covers¶

RBAC + JIT is the access-control lever in a five-lever safety net. The other levers — CI, sharding, progressive rollouts, AI-written e2e tests — enforce correctness. RBAC + JIT enforces authorisation: even if the code is wrong, the actor can only do bounded damage.

Two properties:

RBAC — role-based, not identity-based. Write permissions are attached to roles; agents and humans both get roles; there is no agent-specific carve-out that inflates blast radius. Default posture is least privilege.
JIT — time-bounded, not standing. Elevation to write permissions is issued for a specific task / PR / deploy, expires automatically, and is auditable. No agent (or human) holds standing prod-write access.

Why it matters specifically for agents¶

The five-lever safety net in the source post follows a defence-in-depth logic:

Lever	Bounds what
AI-written e2e tests	Correctness: does code do what it says
CI/CD quality gate	Mechanical correctness: does code build, lint, validate
Sharding / blast radius	Explosion radius: can one failure take down everything
RBAC / JIT access	Authorisation: can this actor even attempt this write
Progressive rollout / canary	Exposure: how many users see a bad version before rollback

Every lever assumes the ones above it may fail. RBAC + JIT answers the question "what if the agent's code is catastrophically wrong and every other lever misses it — what damage is it authorised to do?" If the agent has JIT access limited to a dev-shard namespace, even a compromised / hallucinating agent cannot write to production.

Shape¶

                        Agent
                          │
                          │ attempts write
                          ▼
              ┌───────────────────────┐
              │   RBAC check          │  ← static
              │   role has perm?      │
              └───────────┬───────────┘
                          │
                          ▼
              ┌───────────────────────┐
              │   JIT grant active?   │  ← time-bounded
              │   (ticket, PR, task)  │
              └───────────┬───────────┘
                          │ yes
                          ▼
                   [write allowed]
                          │
                          ▼
                   [audit log entry]
                          │
                          ▼
                   JIT grant expires

Key: the agent is a first-class subject in the RBAC / JIT system, not a proxy for a human's identity. "Control who — and what — can write" — "what" is the agent.

What to scope by role¶

Fine-grained scoping by resource:

Resource	Who needs write	What JIT bounds
Dev shard namespace	Developer's agent, always	Per-developer; scoped to their shard only
Shared dev cluster config	Operator agent, on ticket	JIT grant per ticket
Production config	Operator agent, on MCM	JIT grant per change-management ticket
Secrets store	Agent only via named integration	No direct write; use sealed-secret injection

The principle: grant the minimum role for the minimum time that lets the agent complete the specific task.

Relation to other agent-safety patterns¶

patterns/agent-sandbox-with-gateway-only-egress is the network-level analogue — the agent's outbound connections are gated by a gateway. RBAC + JIT is the API-level analogue — the agent's writes are gated by the access-control system.
patterns/allowlisted-read-only-agent-actions is the capability-level floor — default-read, explicit-write- grants. Similar spirit; different primitive.
patterns/ci-cd-agent-guardrails bundles CI gates + sandbox
access as a coordinated trust-scaling surface. RBAC + JIT is the access-control corner of that bundle.

Trade-offs¶

Operational overhead. JIT grants require a ticketing / elevation surface; agents need a programmatic way to request and receive grants. This infrastructure is not free.
Agent UX friction. An agent that has to wait for a JIT grant on every action has a loopier loop. Balanced against: the grant latency only matters on prod operations, which should be rare in the agent's day-to-day.
Audit overhead. RBAC + JIT is useful because it's auditable — but auditing the agent's actions requires infrastructure to store, analyse, and review audit logs.

When it fits¶

Agent has write access to meaningful resources. If the agent only writes to a dev shard, regular RBAC suffices; JIT matters for prod.
Production access is rare. JIT's cost (grant latency) is bearable when prod writes are occasional, not every-task.
Audit trail is a requirement. Regulated environments, compliance regimes, internal governance all benefit from JIT's timestamped grant records.

Seen in¶

sources/2026-04-24-atlassian-rovo-dev-driven-development — canonical articulation; RBAC + JIT named as the fourth of five levers in the agentic safety net.