Proposed standard · v0.1. This document specifies what our standard requires. It is not an assertion that these controls are implemented, tested, or independently verified in any particular environment, and it is not a SOC 2 report, a certification, or a statement of legal compliance. Missing evidence is unknown, never a pass.
Scope and intent
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.
The standard applies to frontier models, privately hosted models, and enterprise agents with access to tools or organizational data. It is written to be used against one deployment at a time — a named use case, a specific model version, and a specific permission set — because that is the unit that actually holds authority.
The 24 requirements
Controls are grouped into six domains. Every control has a stable identifier that will not be renumbered, so #gcas-14 remains a durable reference. Each states a requirement and the evidence we expect; neither implies that any environment currently satisfies it.
Evaluate models in the system where they will operate
Why this matters. 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.
Requirement Record the use case, business owner, technical owner, affected people, data classes, tools, and maximum authority before deployment.
Evidence we expect A dated system record and approved risk assessment.
GCAS-02 Test the actual deployment.
Requirement 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 we expect A versioned test suite with outcomes and unresolved failures.
GCAS-03 Make approval specific and temporary.
Requirement 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 we expect A release decision, recorded residual risk, expiry, and change history.
GCAS-04 Examine provider dependencies.
Requirement 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 we expect A supplier review and a documented fallback path.
Secure local and private models
Why this matters. 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.
Requirement Record the origin, license, version, and integrity of model weights, images, libraries, and serving components. Review executable model-loading code before use.
Evidence we expect An artifact inventory with hashes and approval records.
GCAS-06 Harden the inference environment.
Requirement Authenticate inference requests; restrict network reachability, service privileges, admin access, and resource consumption. Maintain patching and vulnerability review.
Evidence we expect Deployment configuration, access tests, and a maintenance owner.
GCAS-07 Verify the data boundary.
Requirement 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 we expect A data-flow diagram and observed network behavior under normal and failure conditions.
GCAS-08 Maintain a qualified fallback.
Requirement 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 we expect Evaluation results, capacity limits, and a fallback exercise.
Give every agent limited, attributable authority
Why this matters. 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.
Requirement 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 we expect Identity inventory and attributable access records.
GCAS-10 Issue minimum necessary permissions.
Requirement Default to no access; separately authorize tools, actions, resources, and duration. Use short-lived credentials where supported and broker secrets outside model context.
Evidence we expect Permission policy and denied-access tests.
GCAS-11 Bind approval to the action.
Requirement 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 we expect An approval record linked to the executed action and rejection of altered or replayed approvals.
GCAS-12 Constrain delegation.
Requirement 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 we expect An agent/tool dependency map and tests that delegation cannot expand privilege.
Restrict data access and prove isolation
Why this matters. 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.
Requirement Enforce row, document, tenant, and purpose restrictions before data reaches the model. Start with synthetic or minimized data and explicitly authorize broader use.
Evidence we expect Retrieval authorization tests across users and data classes.
GCAS-14 Test tenant and session separation.
Requirement 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 we expect Cross-tenant and cross-session negative tests with synthetic markers.
GCAS-15 Restrict outbound disclosure.
Requirement 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 we expect Blocked-export tests and access-controlled egress records.
GCAS-16 Govern memory and retention.
Requirement 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 we expect Retention configuration and deletion tests, including documented backup limitations.
Enforce limits outside the model
Why this matters. 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.
Requirement 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 we expect Bypass, stale-policy, and enforcement-outage tests.
GCAS-18 Cap the damage a task can cause.
Requirement 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 we expect Boundary tests showing the enforced stop condition.
GCAS-19 Observe consequential activity.
Requirement 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 we expect Traceable action records and tested alerts with a human response owner.
GCAS-20 Stop authority independently.
Requirement 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 we expect A timed containment drill documenting remaining irreversible effects.
Prepare for the worst credible failure
Why this matters. 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.
Requirement 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 we expect A tabletop or sandbox drill with named responders and recorded decisions.
GCAS-22 Preserve evidence and coordinate response.
Requirement 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 we expect An incident runbook and tested communication paths.
GCAS-23 Restore verified business operations.
Requirement 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 we expect A successful restore or reconciliation drill and a verified fallback procedure.
GCAS-24 Require evidence before restart.
Requirement Remove the failure path, rotate affected credentials, repair or clear compromised memory, repeat relevant evaluations, and obtain accountable human approval before restoring autonomy.
Evidence we expect A remediation record, regression results, and a restart decision.
What a bounded permission actually looks like
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 |
Critical blockers
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
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 reviewUse 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 govern 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
GCAS complements established risk and assurance programs rather than replacing them. The associations below are editorial, to help teams locate our requirements relative to work they already do.
| Guardian domain | 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 |
Scope limitation
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.
Nothing here implies equivalence with, endorsement by, or approval from NIST; SOC 2 certification (SOC 2 results in an examination report, not a certificate); legal compliance; or a substitute for an independent examination.
Sources
- NIST CSF 2.0
- NIST AI Risk Management Framework
- NIST Generative AI Profile (AI 600-1)
- AICPA SOC suite of services
- OWASP Top 10 for Agentic Applications (2026)
- NIST Cyber AI Profile project
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 | Initial proposal for 24 controls and three deployment gates. |
Questions this standard answers
How do you evaluate an AI agent before deployment?
Evaluate the deployment, not the model. Under GCAS-02 the model is tested together with its prompts, retrieval, memory, connectors, and permissions, against realistic tasks and adversarial inputs — including sensitive-data disclosure, prompt injection, incorrect actions, and harmful decisions affecting real people. A published benchmark score describes a model in isolation and cannot tell you whether your configuration will misuse a connected tool.
Are local models automatically private?
No. Local inference is an architecture choice, not a privacy guarantee. GCAS-07 requires documenting and testing outbound telemetry, logs, embeddings, backups, remote dependencies, and cloud fallback. Several of those paths commonly carry content off the host even when the model itself runs locally.
What access should an agent have?
Default to none, then authorize specifically. GCAS-10 requires separate authorization for tools, actions, resources, and duration, with short-lived credentials where supported. GCAS-13 enforces retrieval restrictions before data reaches the model, and GCAS-12 caps delegated authority at what the parent task permits.
Can a kill switch stop queued or delegated work?
Only if it was built to. GCAS-20 requires a control outside the agent’s reach that revokes credentials, blocks egress, disables connectors, and stops scheduled, queued, in-flight where feasible, and delegated work. Stopping generation in a chat window does not tell you what is still running elsewhere, and a timed drill should document which effects remain irreversible.
Does SOC 2 establish that my agent deployment is secure?
No. A SOC 2 examination covers specified controls within a defined system scope against applicable Trust Services Criteria, and it produces a report rather than a certificate. Its existence does not establish that a particular agent deployment is bounded. GCAS-04 asks you to establish what the available assurance evidence actually covers relative to the service you are using.
How should organizations prepare for an agent incident?
Rehearse before it happens. GCAS-21 through GCAS-24 require exercising credible failures, assigning incident command and evidence handling, verifying restore and manual operation, and requiring explicit evidence and human approval before autonomy resumes. Our incident readiness guide walks through the sequence and includes a drill worksheet.
Put the standard to work
Discuss frontier-model evaluation, private-model deployment, agent access design, containment testing, or incident readiness with Guardian Robotics.