Access to a capability must not automatically become permission to use it.
The underlying pattern this scenario illustrates is genuinely implemented in this repository: an existing GGKS provider adapter keeps live execution locked (LOCKED_NO_AUTHORITY) even when a credential is technically configured, until a separate policy authorization is present. This scenario re-presents that same real distinction in a lab-access context.
Gateway as the general mediation point for external tool/model/API access is a real Genesis architectural pattern, illustrated here for a code-execution and deployment-pipeline example.
No real lab code-execution sandbox or production deployment pipeline is connected here.
A frontier model has live API access to a code-execution sandbox and a production deployment pipeline. Having the credential is not the same as being permitted to use it.
The situation
The model has been using the code-execution sandbox for routine analysis all session. It now proposes pushing a change through the same pipeline's production-deployment endpoint, which it can technically reach with the same credential.
What the model / agent knows
- The sandbox execution results so far.
- That the same API surface also exposes a production-deployment endpoint.
- Nothing about whether it has ever been separately authorized for production use.
What it wants to do
Push a change through the production-deployment endpoint.
- Actor
- Frontier model session (synthetic)
- Requested action
- Push a change through the production-deployment endpoint
- Target / system
- Production deployment pipeline
- Scope
- Sandbox execution only, unless separately authorized
- Context
- Same credential reaches both sandbox and production; reachability and authority are checked independently
- Current permission
- —
What capability it can access
- Code-execution sandbox
- Reachable
- Production deployment pipeline
- Reachable
Who has authority?
The credential that reaches the sandbox is the same credential that technically reaches production. Reachability answers a different question than authority does — whether standing was ever separately established for production use is checked independently below.
What Genesis checks
- Whether the credential's reach is being treated as if it were permission.
- Whether a separate, current authorization exists for the specific consequential use (production deployment), independent of sandbox use.
- Principal
- Frontier model session (synthetic)
- Capability reachable
- Sandbox + production pipeline
- Standing for production deployment
- NOT ESTABLISHED
- Scope
- Sandbox execution only, unless separately authorized
Capability is reachable, but reachability alone never establishes authority.
What happens next
The demonstrated consequence boundary returns a refusal for production use whenever standing is not established, regardless of what the "capability reachable" control says — reachability and authority are evaluated as two independent facts, never one standing in for the other.
Inspect the evidence
See the reasoning
This mirrors a real, implemented pattern already in this repository: GGKS's provider adapter locks live execution (LOCKED_NO_AUTHORITY) independent of whether an API credential is configured. Credential presence and policy authorization are checked as separate conditions there too.
Explore the architecture
Genesis components involved: