Permissions demonstration contract

Synthetic record with untrusted note -> simulated tool request -> application-owned Context -> MockGateway policy check -> in-memory mock tool or denial -> audit event -> generated browser report.

The simulation does not parse or execute note text. Scenario requests explicitly represent possible agent behavior. The trusted context and approval registry come from the local test harness; neither comes from the request. Fixtures supply these objects to exercise the policy, not to demonstrate production identity verification.

The exact request envelope is action/string, resource/string, arguments/object. No additional keys are accepted. Read arguments must be empty. Draft/publication arguments must contain only a nonempty text string of at most 2,000 characters. Principal spoofing and embedded approval metadata therefore cannot alter trusted context.

Principals: synthetic-analyst has analyst role; synthetic-operator has operator role. Both can read ops/orders and ops/tickets and create drafts at ops/weekly-report. Only operator may publish_summary at mock/review-board. There are no generic filesystem, shell, network or email tools.

Policy checks run before every dispatch in this gateway: envelope, registered action, exact resource allowlist, principal role, argument schema, and (for publication) approval existence, unconsumed state, approved state, expiry, and exact binding. Expiry is inclusive: expires_at <= trusted_now is denied. A publication consumes approval and appends one in-memory effect. A rejected operation returns no result and does not change draft/publication lists. Read data is returned by copy.

Approval binding includes principal, action, resource, and SHA-256 of canonical JSON arguments. This identifies exact content for this harness; it is not a signed approval, authenticated user identity, or a general security guarantee. Approval state cannot be changed through a tool request. The displayed grants are fixture-owned, not approvals a browser user just granted.

Audit events include sequence, principal, action, resource, approval ID/state before and after, decision, reason, argument digest, and cumulative mock effect count. Lists and approvals reset for each scenario. The audit is ordinary mutable memory, then written as a local JSON report: it is not durable or tamper-evident.

Limitations: synchronous single-process execution; no concurrency/transaction/rollback guarantees; no model, sandbox escape, authentication, data-exfiltration, arbitrary-tool, or production test. Anyone able to change application code or trusted fixture files can change the policy. The demonstration assumes those application-owned inputs are trusted and model-shaped requests are untrusted. Authorization does not validate factual correctness or narrative safety.

Scenario success means exact expected decision sequence, exact reason sequence, and expected counts of mock draft/publication effects all match. Denial is often a successful security fixture. The report's passed/total count uses all declared scenarios, not tool calls or attack attempts, and is not a live-agent security rate. Empty suites must not be interpreted as successful evidence.