Scenario 6
Preview — execution disabledAgentic architectureIntermediateAgent Authorization & Policy Enforcement
An agent can propose any action; a deterministic boundary decides what is allowed to happen.
The central safety principle of an agentic system is that reasoning is not authorizing. A model may plan, argue and conclude that an action is a good idea — but whether that action is permitted to take effect is decided elsewhere, by a deterministic policy that sits outside the model and cannot be talked out of. This scenario is a static architectural walkthrough of that boundary: how a proposed action is checked against policy, permissions and an authorization context before anything happens, and how every decision is recorded.
No action is executed anywhere in this preview. The "actions" are synthetic proposals, and the approvals and denials are illustrative verdicts from a deterministic rule set.
Honesty
Separating the proposer from the authorizer is what makes prompt injection, a confused-deputy mistake or a simply over-eager plan contained by design: the worst a compromised reasoner can do is propose. It cannot grant itself permission.
Preview Mode — Execution Disabled
This laboratory is currently available for architectural exploration and educational demonstrations only. Live agent execution and security testing are disabled. Operational access requires prior explicit authorization from RavenRootviel.
Architecture
Components and flows
The agents, services, verifiers, policy engines and evidence stores in this scenario, and how they connect. Drag to pan, scroll to zoom, and select any component for its role, inputs and outputs.
Agents
Agents and responsibilities
Each agent has a narrow responsibility, explicit inputs and outputs, and — crucially — its own authorization posture. Reasoning is never authorization.
Proposing Agent
Plans toward the task and emits proposed actions (tool calls, writes, external messages) with their arguments and a justification. It never executes.
- Inputs
- Task · Working context
- Outputs
- Proposed action + justification
- Tools
- Planner (reasoning)
- Authorization
- None. The proposer holds no capability to cause side effects; it can only request them.
- Verification
- Its justification is advisory; the authorization decision does not depend on it.
- Possible failures
- May propose an unsafe or out-of-scope action — this is expected and is exactly what the policy boundary contains.
Authorization Context Assembler
Gathers the facts the decision depends on: the acting principal, the delegation chain and its scope, the resource, and the current policy version.
- Inputs
- Proposed action · Principal / delegation token · Resource descriptor
- Outputs
- Authorization context (who, what, on what, under which scope)
- Tools
- Capability / token reader (deterministic)
- Depends on
- proposer
- Authorization
- Read-only; assembles facts, decides nothing.
- Verification
- Scope is read from signed, short-lived credentials rather than inferred.
- Possible failures
- Missing or expired credential — fails closed (treated as no authority).
Capability Verifier
Deterministically checks that the principal actually holds a capability covering this action on this resource, that the delegation scope has not been exceeded, and that the capability has not been revoked or expired.
- Inputs
- Authorization context
- Outputs
- Capability check result (holds / does not hold)
- Tools
- Attenuation / scope checker
- Depends on
- context
- Authorization
- Enforces the capability model; it is part of the boundary.
- Verification
- Pure function of (capability, action, resource); reproducible.
- Possible failures
- Over-broad capability issued upstream — a provisioning error, caught in capability review and visible in the audit log.
Policy Engine
Applies the explicit, deterministic policy to the full authorization context and the capability result, returning APPROVE or DENY with the rule that decided it. Deny by default.
- Inputs
- Authorization context · Capability check result
- Outputs
- APPROVE / DENY + deciding rule · Audit record
- Tools
- Deterministic rule engine
- Depends on
- context · capcheck
- Authorization
- This is the authorization boundary.
- Verification
- Decision is reproducible and logged with the deciding rule and inputs.
- Possible failures
- Policy misconfiguration — surfaced by the audit trail and policy tests, never by relaxing the engine for a demo.
Workflow
Processing and decisions
The ordered path from input to recorded decision.
- 1
Propose
The agent emits a proposed action with arguments and a justification. Nothing is executed.
- 2
Assemble authorization context
The principal, delegation scope, resource and policy version are gathered from signed credentials and descriptors — not inferred from the model’s text.
- 3
Verify capability
A deterministic check confirms the principal holds an in-scope, non-revoked, unexpired capability for this exact action on this resource.
- 4
Decide under policy
The policy engine returns APPROVE or DENY with the deciding rule. Deny by default; anything not explicitly permitted is refused.
- 5
Record and route
The verdict and its full context are logged. An approved action would be dispatched to an executor (disabled here); a denied one is returned to the agent with a reason.
Example execution
Walk through an illustrative trace
A synthetic, predefined sequence — step forward and back to see what each component does, the evidence it produces and the decisions taken. This is a conceptual/synthetic trace, not an executed experiment, and it cannot be run live in this preview.
Step 1 / 5 · Proposing Agent
Synthetic traceAction proposed
To "clean up stale data", the agent proposes delete_records(table="audit_log", where="age > 30d"). It attaches a justification.
Evidence
Evidence in this scenario
What is recorded, of what kind, with what integrity property and from where. Demonstrative data — not cryptographic evidence of a real system.
Capability check result
Deterministic resultIntegrity: Pure function of capability + action + resource
Provenance: Capability Verifier
Authorization context
Assembled factsIntegrity: Scope read from signed, short-lived credentials
Provenance: Authorization Context Assembler
Decision audit record
Audit log entry (synthetic)Integrity: Append-only in a real deployment; demonstrative here
Provenance: Policy Engine
Security controls
Authorization, validation and containment
The mechanisms that make the scenario safe by design, independent of what any model concludes.
Reasoning is not authorizing
The proposer cannot cause effects; only the policy engine can approve an action, and it is deterministic.
Capability-based, least privilege
A principal can only act within a signed, attenuated, revocable capability scope.
Deny by default
Anything not explicitly permitted by policy is refused.
Complete, tamper-evident audit
Every proposal and verdict is logged with the deciding rule and the inputs it saw.
Failure conditions
What can go wrong — and the expected behaviour
Honest failure modes and the containment or recovery that keeps a failure from becoming an unauthorized effect.
Compromised or injected reasoner
The proposing agent is manipulated into proposing a harmful action.
Recovery
Contained by design — the proposal is denied at the boundary; the worst case is a logged, refused attempt.
Expired / missing credential
The delegation token is absent or expired.
Recovery
Fail closed: treated as no authority, action denied.
Over-broad capability issued upstream
A provisioning mistake grants more scope than intended.
Recovery
Caught in capability review; visible in the audit log; never worked around by loosening the engine.
Technical notes
Design considerations, limitations and references
- All actions here are synthetic proposals; nothing is executed and no executor is connected in this preview.
- The separation of proposer and authorizer is the same property demonstrated, at the prompt level, in the Prompt Injection scenario and the in-browser Prompt Injection Lab.
- Capability attenuation, delegation chains and revocation are covered in depth in the Academy (Cryptographic delegation).
References
- OWASP Top 10 for LLM Applications — LLM08: Excessive Agency
- ROOTVIEL Academy — Cryptographic delegation (principal/delegate, scope attenuation, revocation)
- ROOTVIEL Knowledge Base — Insecure agent delegation & the confused deputy
Try this lab
Run it — coming soon
Interactive execution of this scenario is not part of the preview. When it is enabled, it will run on controlled, authorized scenarios only.
Live execution is not available in this preview. Access will require explicit authorization from RavenRootviel.
Authorized Access Only — Live Security Testing
Live security testing and agent execution require prior explicit authorization from RavenRootviel. The current preview provides educational content and non-operational demonstrations only. Browsing the educational content is public; operational use of the labs will require express authorization when it is enabled in a later phase. Access & use policy.