Pinterest Binds Every Code Path to a Role. That Is the Agent Permission Model.

Pinterest runs hundreds of Terraform workspaces governing tens of thousands of AWS resources, and no engineer’s credentials decide what any of those changes are allowed to touch. A config file does. Ammar Ekbote and Chan Kim, Senior Software Engineers at Pinterest, published the design of the Resource Provisioner Pipeline (RPP) this month, and the load-bearing sentence is short: “By linking specific code paths to specific workspaces and roles, we ensure that changes are made in the right environment with the absolute minimal IAM permissions required.”

Read that as Terraform plumbing and you will file it under infrastructure hygiene. It is the cleanest published statement of an agent permission model that exists right now.

Nothing here is a new idea. Least privilege, dual control, and auditable CI have been security orthodoxy for two decades. What Pinterest contributed is the part that keeps getting skipped: a concrete binding format, a concrete gate sequence, and a scale number that makes both credible.

The Binding Is a Config File, Not a Convention

RPP keeps a central workspace-mapping config. Each entry declares four things:

name, the workspace identity
working_directory, the code path this workspace owns
github_repo, the repository that path lives in
agent_iam_roles, the down-scoped roles execution assumes

That is the whole permission surface. Not a wiki page describing who should touch what. Not a review culture where the senior engineer notices something looks wrong. A file that the pipeline reads before it runs anything, where the answer to “what is this change allowed to do” is resolved from the path being changed rather than from the identity of whoever opened the pull request.

The consequence matters more than the format. When permission derives from the path, the author becomes irrelevant to the blast radius. A trusted staff engineer and an autonomous agent opening the same pull request against the same directory get identical capability. Neither can widen it by being persuasive, and neither can widen it by being compromised.

Pinterest also validates the backend block: if the declared state backend does not match the directory being executed in, the build fails. That is the anti-forgery clause. Without it, a change could sit in a governed path and quietly write its state, and its resources, somewhere else.

The Four-Step Gate

Every change walks the same sequence, and each step exists to catch a different failure.

Lint. Static analysis runs on every pull request through custom Semgrep rules alongside Helix and AI integrations. This is the cheap layer, catching pattern-level mistakes before anything expensive runs.

Plan. Terraform plan runs automatically, and a failing plan blocks the merge. The point is not that plan output is informative. The point is that plan failure is a merge-blocking condition rather than a comment someone might read.

Human approval. Code owners approve the pull request. Pinterest is explicit about why this step is not ceremonial: “This intentional step guarantees that code owners are consciously authorizing infrastructure changes.” Ownership is enforced by CODEOWNERS, so the approver is the person accountable for that path, not whoever is online.

Apply. Nothing applies on merge. Apply happens only when someone posts an explicit comment on the pull request. The separation between “this is correct” and “do it now” is preserved as two distinct human acts.

Centralization pays a second dividend Pinterest calls out directly: “If a widespread vulnerability occurs (such as a runner shell vulnerability), we can roll out a fix in a single centralized place instead of modifying hundreds of repositories.” A pipeline copied into three hundred repos is three hundred patch operations. A pipeline every repo calls is one.

Where This Transfers

Terraform is the instance. The pattern generalizes to any agent that writes to a system of record, which is most of the interesting ones.

We have argued before that the bounding box has to come from infrastructure rather than from a prompt, and that permissions belong where the data lives. RPP is what those arguments look like when someone actually builds them and runs them at a scale worth citing.

Substitute the nouns and the structure holds. An agent updating a billing ledger: the binding maps the module path to a database role with write access to exactly the tables that module owns. An agent posting to a CRM: the binding maps the integration path to an API scope covering exactly the objects it may touch. An agent modifying a data warehouse model: the binding maps the model directory to a warehouse role and a specific schema, with the equivalent of backend validation checking that the target schema matches the directory.

The dry-run step transfers too, and it is the one most teams skip. Terraform plan exists because Terraform is declarative. Most systems of record are not, so you have to build the equivalent: a simulated write that produces a readable diff, and a rule that a failed simulation blocks the merge. Without that, human approval is approval of intent rather than approval of effect. The reviewer is agreeing with a description of what the change will do, which is precisely the thing an agent is good at making sound reasonable.

What This Costs You

Honesty about the trade-off makes the pattern easier to sell internally.

Path-bound execution means the workspace boundary and the code layout are now the same decision. Splitting a directory means splitting a workspace and a role. Teams that reorganize repositories casually will feel the friction immediately, and that friction is the mechanism working.

Explicit-comment apply means someone has to be present. For a small change at 4pm on a Friday, that reads as bureaucracy. It is the same bureaucracy that means an agent cannot merge and ship an infrastructure change while everyone is asleep.

Centralized pipelines create a central dependency. When RPP breaks, hundreds of repos are blocked. Pinterest accepts that because the inverse property, patching one place instead of hundreds, is worth more than the availability risk. That math only works if the central pipeline is treated as a tier-one service.

Do This Now

Pick the one agent in your organization with the most write access to a system of record. Open the file, or the wiki page, or the tribal memory that answers “what is this agent allowed to change.” Then ask a single question: is the answer derived from the code path, or from a credential the agent carries?

If it is a credential, you are trusting the author. Rewrite it as a binding. One path, one role, minimum permissions, and a build failure when the declared target does not match the directory being executed in. Then add the dry-run gate and make its failure block the merge. You can add human approval and comment-triggered apply later. The binding is the piece that makes the rest enforceable rather than advisory.

Pinterest did not discover something new. They wrote down the orthodoxy in a form you can copy on Monday, at a scale that removes the excuse that it does not work in the large.

This analysis synthesizes Securing Infrastructure at Scale: Introducing Pinterest’s Resource Provisioner Pipeline (RPP) (Pinterest Engineering, July 2026).

Victorino Group helps engineering organizations turn agent permissions into path-bound bindings their pipelines enforce. Let’s talk.