Least Privilege Assumed You Knew the Path. Agents Decide It at Runtime.

This week Salesforce added another layer of least privilege to Agentforce: a trusted MCP gateway with a server allowlist, agent and server dashboards, and tool-poisoning defenses. The security reflex is correct and the industry is converging on it. Dedicated agent identities, time-bounded credentials, tool-level allowlists, per-server scopes. Everyone is hardening the perimeter around the agent.

It will not be enough, and not because the permissions are too coarse. Least privilege was built on an assumption that agents quietly break.

The assumption underneath least privilege

Least privilege has a hidden premise: that the scope an actor needs is knowable before the actor runs. You map the paths a program can take, you enumerate the resources each path touches, and you grant exactly those. It works because classic software is written once and executes the same way every time. The path exists before the run. You can pre-authorize it.

An agent violates that premise by construction. It does not follow a path you wrote. It composes one at runtime, chaining tools, reusing context from earlier steps, choosing a sequence in response to inputs no policy author ever saw. The scope an agent will need is a function of a decision it has not made yet. You are being asked to pre-authorize a route the agent invents after your authorization was already written.

So an agent can stay strictly inside its granted permissions and still take an action that should never have happened. Every call was allowed. The composition was not. Least privilege is not wrong here. It is incomplete by design, because it cannot see the context that only exists at runtime.

That gap is where the ownable thesis of this memo sits:

Permissions guard the door. The decision boundary guards the action. An identity says who may call. An allowlist says which tool. Only the decision boundary says whether this action should happen, here, now.

Access scope is not decision scope

The subtle error is treating a narrowed set of permissions as if it were a narrowed set of decisions. They are different objects.

Access scope answers: is this agent allowed to touch this resource. Decision scope answers: given everything true about this case right now, is this specific action valid. A refund agent can hold a perfectly scoped permission to issue refunds and still refund an order outside its return window, against a superseded policy version, for a customer whose entitlement data went stale eleven days ago. No permission was exceeded. The decision was still invalid.

You cannot close that gap by making the permission finer. There is no allowlist granular enough to encode "valid only if the policy version in force at decision time still applies to this entity's current state," because that condition is not a property of the tool. It is a property of the moment. This is what The Context Graph named applicability: the rule that governs is the one that applies to this context, evaluated when the decision is made, not when the credential was minted.

Scoping access without scoping decisions is the more expensive of the two half-measures, because it looks complete. The dashboard is green. Every call is authorized. And the agent is one runtime-composed sequence away from a clean, permitted, wrong write.

The control point has to move to the action

If the required scope is only knowable at runtime, then the enforcement has to happen at runtime too, at the moment of the action, not at the moment of authorization.

That is pre-execution enforcement: the agent proposes an action, the system evaluates that proposed action against current, structured context, and only then does it reach a real system of record. The check is not a static grant consulted once at the start of the session. It is a judgment made against the specific action, with flag, escalate, or allow as outcomes, and it produces the reason it decided as it did.

Making that judgment computable is what a decision context graph is for. It holds policy nodes, entitlement facts, contract terms, and approval history as connected, queryable state, so "does this rule still apply to this entity, in this scope, at this version" is a query answered before the write, not a forensic reconstruction after it. Scope isolation then means bounding what the agent may decide, not only what it may call, which is the boundary least privilege was never structured to draw.

This is the same seam The Context Graph traced through agent authorization and MCP policy gates. A permission grants tool access. A gate blocks an unsafe invocation. Neither proves the composed action was applicable to the case in front of it. The allowlist Agentforce shipped this week is a stronger door. It is still a door, not a judgment.

Where the value migrates by mid-2027

Here is the dated prediction. By mid-2027, "runtime scoping" and "decision budgets" will stop being lines in security-posture reports and become a named product layer that enterprise buyers ask for by name. The vendors who shipped only allowlists and dedicated identities will be repriced as commodity plumbing, the way network firewalls were repriced once the value moved up the stack. The margin will follow the layer that evaluates applicability at the moment of action, because that is the layer that actually prevents the permitted-but-wrong write.

The buying question will invert with it. Today procurement asks "how do you scope what the agent can access." In eighteen months it will ask "how do you scope what the agent can decide, and show me where you enforce it." Teams that treated least privilege as the finish line will be re-solving this under incident pressure. Teams that moved the control point to the decision boundary will already have the answer, and the trace to prove it.

The reference implementation

Rippletide is one implementation of this boundary. It lets agents write to production by evaluating each proposed write-action at the moment of the action through Safety Cases, returning flag, escalate, or allow with an auditable trace, then extending runtime enforcement once those Safety Cases are proven. It sits above the identity and gateway layers that Agentforce and Bedrock provide rather than replacing them, which is the point: the allowlist and the decision boundary are different jobs, and only one of them can see the context the agent composed at runtime.

The architectural claim holds independent of vendor. Least privilege assumed you knew the path. Agents decide it at runtime. The only place left to enforce the decision is at the decision.

---

The Context Graph is a weekly newsletter for AI engineers building production agents. Read the context graph glossary for the canonical vocabulary behind the decision boundary, pre-execution enforcement, applicability, scope isolation, and decision context graphs.