05 — Secure gated agent preview access
This appendix is a vendor-neutral control pattern for a temporary review surface. It is not a deployment runbook, an account of current preview exposure, or evidence that a particular network boundary has been measured. A preview can reveal code, tool responses, files, logs, or task context; its access grant therefore needs independent review.
Control objectives
| Objective | Required decision and evidence |
|---|---|
| Named scope | Record purpose, owner, approved reviewer identities, exact service and ports, review window, expiration, and teardown owner before granting access. |
| Separate identity | Use a preview identity distinct from higher-trust operator and control-plane identities. Do not turn a preview path into a management path. |
| Least privilege | Restrict entry at the access gate and the runtime's local network controls to approved reviewers and the intended service. Deny unrelated services and routes. |
| No network expansion | Do not enable subnet routing, exit-node or relay behavior, public sharing, or remote shell merely to make a preview reachable. Any exception needs separate authorization and threat review. |
| Secret custody | Keep join credentials and application secrets outside the repo, prompts, transcripts, logs, and receipts; reference protected secret storage rather than copying values. |
| Reversibility | Define the steps and owner for closing the service, withdrawing the grant, revoking the temporary identity/credential, and removing temporary network state before opening access. |
| Evidence | Record sanitized authorization, permitted and denied reachability checks, readiness, expiration, and inactive-state checks. A configuration file alone does not prove these behaviors. |
A private overlay, access proxy, bastion, or comparable gate can satisfy the objectives when its actual policy and runtime behavior are verified. No particular vendor, daemon, interface, port range, firewall syntax, or topology is required by this appendix. Firewall changes must be designed against the existing ruleset and management path; a new input-hook chain with a global policy drop can interrupt unrelated traffic and is not a safe generic example.
Safe validation checklist
Perform this review in the approved environment with an operator-specific, separately reviewed procedure. Do not treat this page as authorization to change live access.
- [ ] Identify the preview data classification and confirm it contains no production secrets or sensitive data outside the reviewer's authorization.
- [ ] Record the owner, reviewers, exact service/port, expiration, approval, and rollback owner. Confirm the normal management path remains independent and reachable.
- [ ] Review the proposed access policy and local firewall change against the existing configuration before applying it. Verify that it does not widen routes, public sharing, remote shell, or unrelated listeners.
- [ ] Confirm the running service is the intended artifact and that application authentication and expected-host checks, where applicable, remain in force.
- [ ] From an approved reviewer identity, check the intended preview path. From a disallowed identity and another unintended service/port, check denial. Record the result and scope; a single success or refusal is not a universal isolation claim.
- [ ] Check the approved expiration and access records without exposing credentials. Only then issue a time-bound readiness notice.
- [ ] At closure, stop the preview service, withdraw the access grant, revoke or expire temporary credentials and identities, and remove only the temporary resources identified for this review.
- [ ] Independently check that the preview listener and grant are inactive, denied access remains denied, and the normal management path still works. Record a secret-free teardown receipt.
Stop and rollback criteria
Stop before opening access if ownership, approval, data classification, a bounded scope, the independent management path, or a reversible change plan is missing. Do not improvise a broad firewall rule or copy credentials into command lines to make the preview work.
Close the preview immediately and follow the approved rollback procedure if an unapproved identity or port can reach it, the service becomes publicly reachable, the management path is affected, a credential appears in output or a public artifact, the service differs from the reviewed artifact, or the expiration/teardown owner is lost. If rollback cannot be verified, keep the preview closed, preserve a sanitized incident record, and escalate to the operator; do not mark the session complete.
Publication boundary
A published example or receipt must use fictional values and omit live routes, identities, credentials, raw transcripts, and private topology. Run the repository's public safety scan and manually apply the declassification checklist before publication. A scanner result does not prove safe exposure or successful teardown.
This gate complements workload containment, default-deny egress, explicit promotion, audit, and separately demonstrated rollback. It does not establish production readiness, current isolation, or a completed recovery drill.