The execution broker in 60 seconds
The dangerous component in an AI pentest system is not necessarily the model. It is the function that turns a model response into authority.
An agent can correctly identify a cross-tenant authorization weakness and still choose an unsafe proof. It can correctly understand an Active Directory relationship and still run the wrong command under an inherited privileged session. Better reasoning reduces some errors. It does not make a general-purpose credential safe to hand to a probabilistic planner.
The previous article in this route established the operating rule: the model proposes, policy authorizes, a least-privileged worker executes, and an independent path verifies. This article turns that rule into an implementable boundary.
The companion Execution Broker Lab is a target-free, browser-only simulation. It contains no cloud API, directory connection, shell, or credentials. It is a reference policy model—not a production security product, a measured benchmark, or evidence that these controls have protected a live engagement.
Start with the security property
“The agent asks for confirmation” is not a sufficient security property. A confirmation dialog can hide the resolved target, inherit the wrong identity, approve a broad class of actions, or appear after the system already obtained a privileged token.
The property we want is narrower:
A model-directed worker can execute only a typed operation for a resolved in-scope target, using a short-lived capability whose identity, effect, object count, and expiry were independently authorized.
That sentence separates four responsibilities:
- The model supplies a proposal and rationale.
- The broker resolves trusted facts and makes a deterministic decision.
- The worker receives only the capability required for one bounded job.
- The verifier observes scope and state through a separate path.
The model does not resolve its own target, grant its own scope, select its own effective identity, approve its own side effect, or grade its own result.
Four planes, four different trust decisions
An execution broker is easier to reason about when it is split into four planes.
Proposal plane
The model produces structured intent: operation, candidate target, expected effect, reason, and evidence goal. Everything in this plane is untrusted. A proposal may be mistaken, manipulated by retrieved content, derived from stale memory, or entirely fabricated.
Policy plane
The broker replaces aliases with trusted facts. It looks up the engagement, resolves the target, maps the operation to a typed tool contract, determines the effective identity, calculates the maximum object count, and classifies the side effect. These facts come from registries the model cannot edit.
Execution plane
An isolated worker receives a narrowly scoped capability after policy allows the request. It does not inherit the operator’s shell, browser, SSH agent, cloud CLI session, Kubernetes context, or directory token. A capability is bound to one resource audience, operation, scope, expiry, and job.
Evidence plane
The original proposal, resolved facts, decision, approval, capability, worker result, independent state observation, negative control, and cleanup status form one append-only record. A denial is also evidence: it must show that no capability was issued and no worker job was created.
The tool catalog is a security boundary
An agent cannot exercise functionality it cannot reach. That makes tool inventory reduction more valuable than adding another sentence to the system prompt.
OWASP’s Excessive Agency guidance identifies excessive functionality, permission, and autonomy as root causes. A document reader that also exposes delete, a database connector that permits mutation, or a legacy extension left in the catalog increases impact even if the model normally selects the safe operation.
Every tool contract should declare at least:
- a stable operation name;
- accepted and rejected argument shapes;
- side-effect class;
- allowed environments;
- maximum object and result count;
- required identity class;
- whether retry is safe;
- approval class;
- evidence emitted on success, failure, and timeout.
{
"operation": "directory.object.inspect",
"effect": "read",
"environments": ["lab", "production"],
"identity_class": "audit_reader",
"max_objects": 50,
"automatic_retry": false,
"approval": "none",
"evidence": ["scope_id", "query_id", "result_count", "verifier_result"]
}Do not describe a general-purpose shell as read_only because the intended command reads data. The
capability includes every executable, file, credential, socket, and inherited session available to
the process. That is a worker isolation problem, not a naming problem.
The current MCP Tools specification says users should be able to deny tool invocations and applications should clearly expose tools, show invocation, and present confirmations. It also allows the visible tool set to vary with the authorization on the request. That supports a useful design: the model should not even discover high-impact tools when its current capability is L0 or L1.
Protocol support does not create policy by itself. The application must still classify operations, resolve targets, constrain identities, and decide what never becomes autonomous.
Resolve before approval
The model may propose customer-backup, prod-east, or corp.local. Those are aliases, not safe
authorization inputs. The broker resolves them through trusted engagement and asset registries.
Before showing an approval, the system should know:
| Proposed value | Broker-resolved fact |
|---|---|
| Target alias | Canonical tenant, subscription, account, domain, host, and object identifier |
| Tool name | Versioned operation and effect class from the catalog |
| “Current user” | Effective worker identity and granted scopes |
| “A few objects” | Exact object set and enforced maximum |
| “Can be reverted” | Tested recovery reference and current recovery status |
| “Safe to retry” | Idempotency contract and request identifier semantics |
The approval binds to the resolved facts. If the target, operation, identity, object count, expected state difference, recovery reference, or expiry changes, the approval is invalid.
This is where a generic “Are you sure?” fails. It approves intent while the dangerous details remain unresolved.
Use a capability ladder, not a safe/unsafe flag
A single dangerous: true property cannot express the operational difference between offline
analysis, bounded inventory, a reversible lab change, and production deletion. The lab uses four
levels:
L0 — Offline
No target connection or credential exists. Saved-artifact analysis, hypothesis generation, schema comparison, code review, and report drafting belong here. These tasks can be autonomous within data handling constraints because they cannot create an external side effect.
L1 — Bounded read
The broker may issue a short-lived read identity when the target matches scope, the worker is isolated, the operation has a result cap, and a separate path verifies scope and result. Read-only is an operation contract, not an assumption based on an HTTP method or command name.
L2 — Reversible lab action
One named, engagement-owned canary in a controlled lab may receive a single-use capability. The broker requires a verified recovery path, parameter-bound approval, no automatic retry, a lab-only identity, and independent verification of both the state change and rollback.
L3 — High impact
Deletion, production mutation, credential reset, privilege change, broad data access, and administrative shells are denied to model-directed execution. The model may prepare a plan or evidence package. It does not receive the capability.
This is a policy decision, not a statement that L3 work can never be performed by an authorized human workflow. It says L3 authority should not be created for ordinary autonomous execution.
Authorization should be incremental and resource-bound
The current MCP authorization draft uses protected resource metadata, explicit resource indicators, least-privilege scope selection, and step-up authorization when an operation needs more scope. It also limits repeated retries after an authorization failure.
Those ideas translate well to a pentest broker:
- obtain no target credential during offline planning;
- request a read scope only when the L1 operation is ready;
- bind the token to the intended resource server rather than accepting it for any connector;
- issue short-lived capabilities after policy, not before proposal generation;
- track authorization upgrades so a planner cannot loop until a user accepts;
- never let accumulated scopes silently turn an L1 session into an L3 session.
Transport authorization answers whether a client can reach a protected server. Object and engagement authorization still have to answer whether this identity may perform this operation on this resolved target during this assessment.
A retry is another action
Tool orchestration often treats timeouts as infrastructure noise. That is safe only when the operation is idempotent and the server’s semantics are known.
A mutating request can reach the target, commit, and lose the response. If the agent retries, it may repeat a change, advance a state machine twice, create another object, or act on a target whose preconditions have already changed.
The broker therefore records three outcomes separately:
- failed before send — no target action occurred; a bounded retry may be safe;
- definitive target rejection — no state change occurred; remediation or revised authorization may be needed;
- ambiguous after send — execution pauses and an independent read path determines state.
Automatic retry is disabled for L2. L3 never receives a capability. A model cannot reinterpret an ambiguous result as permission to try again.
Approval must expose the real blast radius
An L2 approval should show:
- engagement and policy version;
- canonical target and named canary owner;
- operation and side-effect class;
- effective worker identity;
- exact object count and enforced maximum;
- expected pre-state and post-state;
- recovery reference and last verified time;
- automatic retry status;
- independent verification path;
- expiry and immutable approval identifier.
The approval record is hashed or otherwise bound to these parameters. Any change creates a new proposal and requires a new decision.
The NIST concept paper on software and AI agent identity highlights the risk created when agents receive access to diverse tools, applications, and data, and frames agent identity and authorization as a distinct control problem. In pentesting, written rules of engagement remain the source of authority. The broker makes part of those constraints machine-enforceable; it does not expand them.
Walk the six lab scenarios
The interactive lab includes six synthetic proposals.
- Offline hypothesis review receives L0 approval because no identity or external effect exists.
- Scoped directory inspection receives an L1 read capability only while scope, isolation, count, and independent verification remain valid.
- Reversible lab canary receives one L2 capability because every lab gate is present. Disable recovery, named canary, bound approval, worker isolation, or verification and the decision moves to hold.
- Production cloud deletion is denied because the effect is destructive, the identity is broadly privileged, the worker is not isolated, approval is generic, and retry is unsafe.
- Domain Admin shell is denied because a general shell under ambient Domain Admin authority is outside the autonomous capability model.
- Prompt-influenced scope drift is denied even though the requested effect is read-only. The resolved target is outside the engagement registry.
Change one field at a time. The point is not to find a combination that tricks the simulator into allowing deletion. The point is to see which facts belong to deterministic policy and which risks cannot be reduced by model confidence.
The lab can download its current decision as JSON. The record is created locally in the browser and contains only the synthetic or user-edited values on the page. Do not paste real credentials, tokens, customer data, or production identifiers into it.
The field kit
Two reusable artefacts accompany the lab:
- Policy contract JSON — capability levels, mandatory gates, denial rules, proposal fields, approval binding, and decision records.
- Evidence worksheet CSV — a working record for proposal, resolved scope, identity, decision, capability, execution, verification, negative control, rollback, and evidence limits.
They are intentionally deployment-neutral. They do not issue tokens or connect to a target. Adapt them to the organization’s identity provider, engagement system, tool server, worker isolation, logging, retention, and incident response model.
Evidence matrix
| Security claim | Positive evidence | Negative control | Failure signal | Explicit limit |
|---|---|---|---|---|
| The model cannot authorize its own tool call | Proposal exists without a credential; broker decision precedes capability issuance | Change an approved parameter after decision and confirm the approval becomes invalid | A worker token exists before policy resolution | The browser lab demonstrates logic, not production isolation |
| Scope is resolved outside model context | Canonical target and engagement ID come from a protected registry | Propose an alias that resolves outside scope and confirm denial | Model-provided target is accepted without lookup | Registry integrity requires separate controls |
| L1 reads are bounded | Read identity, object cap, expiry, isolated worker, and verifier are recorded | Exceed the object cap and confirm no capability is issued | Result set grows without a policy event | Read-only does not prove absence of resource consumption or sensitive disclosure |
| L2 changes are reversible lab actions | Named canary, pre-state, bound approval, post-state, rollback, and verifier result exist | Remove recovery verification and confirm hold | Lab change executes with generic confirmation | Lab rollback does not prove production recoverability |
| L3 authority cannot reach autonomous execution | Delete and Domain Admin proposals produce denial and no capability/job | Submit an allowed L1 proposal and confirm the normal worker path still functions | High-impact tool remains discoverable or executable | Human-controlled high-impact workflows are outside this model |
| Ambiguous mutation does not retry | Timeout state pauses and independent verification determines target state | Repeat a known idempotent read within its retry cap | Second mutation occurs before state resolution | Target-specific idempotency must be independently documented |
Implementation sequence
Do not begin by placing a policy prompt in front of an existing privileged agent. Build the control path in this order:
- Inventory every currently exposed tool and effective identity.
- Remove unused, overlapping, destructive, and general-purpose functionality.
- Define versioned operation contracts and side-effect classes.
- Build an engagement registry that resolves canonical targets and testing windows.
- Separate L0, L1, and L2 workers and credentials. Keep L3 outside model-directed execution.
- Implement deterministic denial rules before approval UX.
- Bind approval to resolved parameters and expiry.
- Issue one short-lived, resource-bound capability per allowed job.
- Record proposal, policy, approval, capability, worker result, and verification separately.
- Test negative controls: scope mismatch, cap exceeded, stale approval, ambient administrator, unsafe retry, and unavailable recovery.
- Add a kill switch that prevents new capability issuance and revokes active short-lived access.
- Rehearse ambiguous results, cleanup, and incident notification in the controlled lab.
Only after those controls pass should the organization consider increasing automation. Model benchmark performance is not a substitute for control-plane testing.
What this design does not solve
An execution broker reduces one class of excessive agency. It does not make every connected system safe.
The engagement registry can be wrong. A tool can misclassify its side effect. The identity provider can issue an excessive token. A worker can escape isolation. The target API can behave differently from its documentation. Logs can omit the decisive event. A malicious tool server can lie about its schema or result. An operator can approve a dangerous request.
Each boundary requires its own test and evidence. The broker is valuable because it creates a place to enforce and observe those decisions. It is not a universal trust anchor.
The operating conclusion
The safest AI pentest agent is not the one with the longest prohibition prompt. It is the one whose ordinary execution path cannot create broad authority.
Let the model explore hypotheses and prepare structured proposals. Let deterministic policy resolve scope, identity, effect, count, retry, approval, and recovery. Give isolated workers the smallest short-lived capability that can accomplish the approved proof. Verify through another path. Record denials as carefully as executions.
If the model proposes production deletion or a Domain Admin shell, the broker’s job is not to ask more persuasively. It is to ensure that capability never exists.
MITRE ATT&CK mapping
| Tactic | Technique ID | Technique name | Verification signal |
|---|---|---|---|
| Execution | T1059 | Command and Scripting Interpreter | Deterministic broker denies shell execution from model plan |
| Privilege Escalation | T1548 | Abuse Elevation Control Mechanism | Parameter-bound capability issuance gates worker elevation |
| Defense Evasion | T1078 | Valid Accounts: Ambient Authority | Short-lived single-use credentials prevent ambient credential reuse |
Test capability ladder decisions, policy gates, and scope boundaries interactively in your browser with reproducible execution scenarios.
Launch Interactive Broker ↗How current is this note?
The latest source-review, content-update, or publication date is shown.
The author completed a technical review. This does not, by itself, claim lab reproduction.