# Guardian Controlled Autonomy Standard **GCAS v0.1 — Proposed standard** **Publisher:** Guardian Robotics **Draft date:** September 28, 2026 **Applies to:** Frontier models, privately hosted models, and enterprise agents with access to tools or organizational data. **Canonical page:** https://gov.guardianrobotics.com/ai-governance/controlled-autonomy-standard.html > Autonomy must be earned, bounded, and revocable. Our proposed policy is straightforward: before an AI system receives authority, its owner must demonstrate the controls appropriate to its task, data, and potential impact. Models may propose actions. Independently enforced policy determines what executes. People remain accountable for granting authority and accepting residual risk. This document specifies our proposed requirements. It does not assert that Guardian or another organization has implemented or independently verified them. It complements established risk and assurance programs; it is not a SOC 2 report or an external certification. ## Contents - Evaluate models in the system where they will operate (GCAS-01 – GCAS-04) - Secure local and private models (GCAS-05 – GCAS-08) - Give every agent limited, attributable authority (GCAS-09 – GCAS-12) - Restrict data access and prove isolation (GCAS-13 – GCAS-16) - Enforce limits outside the model (GCAS-17 – GCAS-20) - Prepare for the worst credible failure (GCAS-21 – GCAS-24) - Deployment gates - Evidence record template - How we use AI to manage AI - Thematic framework crosswalk - Governance and revision ## The 24 controls ### Evaluate models in the system where they will operate _A model evaluated on its own is not the system you are deploying. Prompts, retrieval, memory, connectors, and permissions change behaviour, and the combination is what acts on your business._ - [ ] **GCAS-01 — Assign an accountable owner.** Record the use case, business owner, technical owner, affected people, data classes, tools, and maximum authority before deployment. **Evidence:** A dated system record and approved risk assessment. - [ ] **GCAS-02 — Test the actual deployment.** Evaluate the model together with its prompts, retrieval, memory, connectors, and permissions against realistic tasks and adversarial inputs. Include sensitive-data disclosure, prompt injection, incorrect actions, and harmful decisions relevant to affected people. **Evidence:** A versioned test suite with outcomes and unresolved failures. - [ ] **GCAS-03 — Make approval specific and temporary.** Define measurable acceptance thresholds and a reassessment date for a named use case, model version, and permission set. Retest material changes to models, prompts, tools, memory, or access; suspend affected authority if new behavior exceeds the approved boundary. **Evidence:** A release decision, recorded residual risk, expiry, and change history. - [ ] **GCAS-04 — Examine provider dependencies.** Review applicable data handling, retention, training use, subprocessors, hosting locations, incident notification terms, and service continuity. Establish what the available assurance evidence actually covers. **Evidence:** A supplier review and a documented fallback path. ### Secure local and private models _Self-hosting moves the model, not necessarily the data. Telemetry, logs, embeddings, backups, remote dependencies, and cloud fallback can each carry content outside the boundary you believe you have._ - [ ] **GCAS-05 — Control model provenance.** Record the origin, license, version, and integrity of model weights, images, libraries, and serving components. Review executable model-loading code before use. **Evidence:** An artifact inventory with hashes and approval records. - [ ] **GCAS-06 — Harden the inference environment.** Authenticate inference requests; restrict network reachability, service privileges, admin access, and resource consumption. Maintain patching and vulnerability review. **Evidence:** Deployment configuration, access tests, and a maintenance owner. - [ ] **GCAS-07 — Verify the data boundary.** Document and test outbound telemetry, logs, embeddings, backups, remote dependencies, and cloud fallback. Local inference alone does not establish that all data stays local. **Evidence:** A data-flow diagram and observed network behavior under normal and failure conditions. - [ ] **GCAS-08 — Maintain a qualified fallback.** Benchmark the selected local configuration for its authorized tasks and rehearse capacity exhaustion or model unavailability. Any fallback must have equal or narrower approved data access. **Evidence:** Evaluation results, capacity limits, and a fallback exercise. ### Give every agent limited, attributable authority _Agents are routinely deployed with whatever credential was convenient. Authority that was never scoped cannot be reasoned about, revoked precisely, or attributed after an incident._ - [ ] **GCAS-09 — Use a distinct agent identity.** Attribute access to a named agent and responsible owner. Use scoped service identities rather than a person's unrestricted account or shared administrator credentials. **Evidence:** Identity inventory and attributable access records. - [ ] **GCAS-10 — Issue minimum necessary permissions.** Default to no access; separately authorize tools, actions, resources, and duration. Use short-lived credentials where supported and broker secrets outside model context. **Evidence:** Permission policy and denied-access tests. - [ ] **GCAS-11 — Bind approval to the action.** Require independent human approval for defined high-impact actions such as payments, bulk deletion, permission changes, and consequential external commitments. Bind approval to recipient, resource, parameters, time limit, and scope; changed actions need new approval. **Evidence:** An approval record linked to the executed action and rejection of altered or replayed approvals. - [ ] **GCAS-12 — Constrain delegation.** Child agents and connected tools must receive no more authority than the authorized parent task permits. Restrict delegated credentials, recursion, tool registration, and the ability to spawn more agents. **Evidence:** An agent/tool dependency map and tests that delegation cannot expand privilege. ### Restrict data access and prove isolation _Retrieval that searches an entire corpus regardless of who is asking is an access-control failure even though no conventional permission was bypassed. Shared caches, queues, vector indexes, and persistent memory each create a path between contexts._ - [ ] **GCAS-13 — Limit retrieval at the source.** Enforce row, document, tenant, and purpose restrictions before data reaches the model. Start with synthetic or minimized data and explicitly authorize broader use. **Evidence:** Retrieval authorization tests across users and data classes. - [ ] **GCAS-14 — Test tenant and session separation.** Isolate identities, workspaces, browser state, files, caches, queues, vector indexes, and persistent memory. Test both concurrent use and reuse after cleanup. Shared infrastructure requires demonstrated boundaries; dedicated infrastructure still requires controls. **Evidence:** Cross-tenant and cross-session negative tests with synthetic markers. - [ ] **GCAS-15 — Restrict outbound disclosure.** Apply destination allowlists, export limits, and appropriate content checks to tools, messages, uploads, and network traffic. Prevent an agent from turning a new connector into an unauthorized exit path. **Evidence:** Blocked-export tests and access-controlled egress records. - [ ] **GCAS-16 — Govern memory and retention.** Define purpose, access, retention, and deletion for prompts, outputs, logs, and persistent memory. Keep secrets out of model context where practical; verify cleanup on session termination and tenant teardown. **Evidence:** Retention configuration and deletion tests, including documented backup limitations. ### Enforce limits outside the model _If the only thing preventing a prohibited action is an instruction in the prompt, then any content the model reads can attempt to override it. Limits must be enforced by something the model cannot reach._ - [ ] **GCAS-17 — Put authorization at the execution boundary.** Use independent enforcement to check each tool action against identity, scope, resource, approval, and current policy. Untrusted content cannot authorize action. Deny new privileged actions when authorization cannot be verified. **Evidence:** Bypass, stale-policy, and enforcement-outage tests. - [ ] **GCAS-18 — Cap the damage a task can cause.** Set per-task and aggregate ceilings for spending, runtime, tool calls, concurrency, data exports, and records changed. Enforce limits across retries and child agents. **Evidence:** Boundary tests showing the enforced stop condition. - [ ] **GCAS-19 — Observe consequential activity.** Record action requests, authorization decisions, approvals, tool results, state changes, and agent identity in protected logs. Minimize sensitive content. AI may assist detection and investigation, but cannot independently grant broader access or suppress oversight. **Evidence:** Traceable action records and tested alerts with a human response owner. - [ ] **GCAS-20 — Stop authority independently.** Provide a control outside the agent's reach to revoke credentials, block egress, disable connectors, and stop scheduled, queued, in-flight where feasible, and delegated work. Stopping generation alone is insufficient. **Evidence:** A timed containment drill documenting remaining irreversible effects. ### Prepare for the worst credible failure _Containment procedures that have never been exercised tend to fail in the specific ways nobody anticipated. The first rehearsal should not be the actual incident._ - [ ] **GCAS-21 — Rehearse realistic incidents.** Exercise unauthorized messages, bulk deletion, exfiltration, cross-tenant exposure, malicious tools, model/provider compromise, runaway spending, and cascading agent failures. Include control-plane failure and physical consequences where agents affect equipment. **Evidence:** A tabletop or sandbox drill with named responders and recorded decisions. - [ ] **GCAS-22 — Preserve evidence and coordinate response.** Assign incident command, severity criteria, evidence handling, escalation, and notification decision owners. Contain the incident while preserving useful evidence where feasible; avoid duplicating sensitive data unnecessarily. **Evidence:** An incident runbook and tested communication paths. - [ ] **GCAS-23 — Restore verified business operations.** Maintain protected backups, recovery targets, reconciliation procedures, and a manual operating mode. Measure recovery time and data loss during exercises. External disclosures and messages require consequence management; a restore cannot undo them. **Evidence:** A successful restore or reconciliation drill and a verified fallback procedure. - [ ] **GCAS-24 — Require evidence before restart.** Remove the failure path, rotate affected credentials, repair or clear compromised memory, repeat relevant evaluations, and obtain accountable human approval before restoring autonomy. **Evidence:** A remediation record, regression results, and a restart decision. ## Bounded permissions in practice A support agent is authorized to read an approved subset of tickets and draft a response. That authorization does not extend by implication: Within the authorization: - Read tickets within the authorized subset. - Draft a response inside its approved workflow. Requires separate authority: - Sending a message outside its approved workflow requires a separately authorized capability and the applicable approval. - Exporting a customer list is a different action class, not a larger version of reading one ticket. - A child agent it spawns does not inherit unrestricted access; delegated authority is capped by the authorized parent task. The distinction is between what a model can propose and what independently enforced policy will execute. ## Deployment gates Use the same controls at different depths according to documented risk. These gates are Guardian's proposed deployment states, not certifications or scores. | State | Permitted authority | Evidence required to advance | |---|---|---| | Sandbox | Synthetic or public test data; isolated tools; no production credentials | Owner, threat assessment, scoped evaluation plan, artifact and provider review | | Constrained pilot | Explicitly approved data subset; read-only or individually approved writes; quotas | Passed boundary tests, access and isolation evidence, monitoring, tested stop mechanism | | Bounded production | A defined set of actions within approved limits and change control | All applicable controls evidenced, incident and recovery exercise, authorized residual-risk decision, review expiry | Missing evidence is **unknown**, not a pass. Reproducible failures involving unauthorized access, tenant separation, high-impact approval bypass, or inability to stop authority block the affected deployment from promotion. Change the scope or fix and retest the control. For other exceptions, document the owner, affected scope, reason, compensating controls, accepted residual risk, approval, and expiration. A checkbox count never overrides a critical failure. ## Evidence record template For every applicable control, record: `Control ID | System/version | Owner | Requirement | Test method | Expected result | Observed result | Evidence location | Status | Exception/expiry | Reviewed date | Next review` Use statuses **Pass**, **Fail**, **Unknown**, **Not applicable with rationale**. Keep sensitive evidence private; publish only appropriately reviewed summaries. This draft checklist starts unassessed. ## How we use AI to manage AI Our proposed policy permits AI-assisted test generation, anomaly detection, evidence summarization, and incident triage — under the same access and data controls that apply to any other system. Detection models can be wrong, and they can be compromised. Independent authorization controls enforce limits; accountable people approve authority changes and incident restart. The monitor is another system to evaluate, not an infallible judge. ## Thematic framework crosswalk These are Guardian's editorial associations, not equivalence, certification, or comprehensive coverage. SOC 2 relevance depends on the examination scope and applicable criteria. The mapping was prepared from publicly available overviews; the full AICPA Trust Services Criteria download and the SOC 2 guide are gated resources that were not reviewed in full. Treat this table as a thematic planning aid, not an auditor-validated criteria mapping. | Guardian domain | GCAS controls | CSF functions | Relevant SOC 2 categories | |---|---|---|---| | Model and deployment evaluation | 01–04 | Govern, Identify | Security, Processing Integrity | | Private and local deployment | 05–08 | Identify, Protect | Security, Confidentiality, Privacy | | Agent identity and authority | 09–12 | Govern, Protect | Security, Processing Integrity | | Data boundaries and isolation | 13–16 | Protect | Security, Confidentiality, Privacy | | Runtime containment | 17–20 | Protect, Detect, Respond | Security, Availability, Processing Integrity | | Incident readiness and recovery | 21–24 | Respond, Recover | Security, Availability | Nothing above implies equivalence with, endorsement by, or approval from NIST; SOC 2 certification; legal compliance; or a substitute for an independent examination. ## Governance and revision Guardian Robotics is the proposed standard maintainer. Assign a named internal policy owner before adoption. Review at least quarterly and after material incidents, architecture changes, or relevant new evidence. Preserve stable control IDs and a dated change log; publish substantive revisions with reasons. Record policy adoption separately from evidence of implementation. | Version | Date | Change | |---|---|---| | v0.1 | September 28, 2026 | Initial proposal for 24 controls and three deployment gates. | ## Put the standard to work Discuss frontier-model evaluation, private-model deployment, agent access design, containment testing, or incident readiness with Guardian Robotics. - Contact: https://gov.guardianrobotics.com/contact.html - Email: info@guardianrobotics.com ## Status and limitations This document states requirements. It does not assert that Guardian Robotics or any other organization has implemented, tested, or independently verified them. It is not a certification, a SOC 2 report, or a statement of legal compliance. Missing evidence is **unknown**, not a pass. ## Foundations GCAS is Guardian's proposed operational policy. Framework associations are explanatory and do not imply endorsement or compliance. The thematic crosswalk and its scope limitation are published on the standard page: https://gov.guardianrobotics.com/ai-governance/controlled-autonomy-standard.html#crosswalk - [NIST CSF 2.0](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [NIST Generative AI Profile (AI 600-1)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) - [AICPA SOC suite of services](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services) - [OWASP Top 10 for Agentic Applications (2026)](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) - [NIST Cyber AI Profile project](https://www.nccoe.nist.gov/projects/cyber-ai-profile) --- © 2026 Guardian Robotics. Guardian Controlled Autonomy Standard v0.1 (Proposed standard).