Architecture · Capability Control

AI agent capability control: constrain what an agent is allowed to do

Capability control is the enforcement layer between an agent's intent and a real-world action. The goal is not to make the agent less useful; it is to make authority explicit, bounded and auditable before a mutation happens.

CLAIM ≠ PROOF. No evidence = UNKNOWN.

A model may be able to reason about a repository, deployment or financial action without being authorized to perform it. Capability control separates what the agent can infer from what the runtime lets it change.

INTENT → POLICY → AUTHORITY → TOOL / CAPABILITY → REPOSITORY + FILE SCOPE → EXACT PAYLOAD → EXECUTION → EVIDENCE

The enforcement point must sit upstream of mutation. If a downstream runtime can open its own write window, a policy document or UI approval badge does not provide meaningful control.

OSA Execution Force implements this pattern through GODMODE V3. The authority decision binds the selected policy card, repository, allowed scope, source commit SHA, task digest and exact RuntimeV2 payload before downstream execution can proceed.

The documented P0 invariants deny direct RuntimeV2 mutation before V3 authorization, reject modified policy payloads, prevent scope widening and invalidate an older downstream action when a new authorization is created.

Mutation authority is only meaningful if it is attached to a known code snapshot. The V3 path requires source_commit_sha to be an exact 40-character Git SHA. Missing or UNKNOWN provenance fails closed rather than being silently upgraded to trusted state.

Repository scope, file scope, payload and source provenance are separate bindings. A correct repository with a modified payload is still a different action.

Hydra Hermes Lab adds an operational permission layer around a sandboxed runtime. The public control plane classifies actions into GREEN, YELLOW and RED paths and exposes approval-aware queue operations. Baseline integrations such as web search, messaging, MCP servers and custom plugins are disabled until they are intentionally introduced.

That creates a second boundary: authorization decides whether an action is permitted, while the sandbox and runtime decide which capabilities physically exist in the execution environment.

The Execution Force repository publishes a mechanical authority workflow and an evidence ladder: CLAIMED → ARTIFACT_PRESENT → MECHANICALLY_VERIFIED → INDEPENDENTLY_VERIFIED. A model saying that it was authorized is not equivalent to evidence that the correct authority gate approved the exact action.

The checked P0 launcher emitted provenance evidence and the project-scoped V3 hook suite reported 11 passing tests. The repository explicitly does not claim that this proves universal enforcement across every host or deployment topology.

QuestionRequired evidence
Who authorized the action?Policy and authority record.
What code snapshot is acting?Immutable source SHA.
What may change?Repository, file and operation scope.
Which exact request was approved?Bound payload and digest.
Can downstream code widen the scope?Fail-closed enforcement tests.
Can the action be stopped?Cancellation, circuit breaker or operator stop.
How is success checked?Independent observations and proof.