Skip to content
§ II · Domain SPC
Controls
9
Edition
v.1.2

SPC · Domain 2 of 9

Agent Specification & Pre-Deployment Assurance

Behavior, capabilities, and constraints validated before deployment and on material change.

SPC requires that every agent has a written specification of its intended behavior, its operating envelope, and the conditions under which it must escalate. Pre-deployment assurance attests that the specification is testable, the agent has been tested against it, and material changes trigger re-attestation.

Table SPC.1 · Controls in SPC · v.1.29 controls · 5-level maturity
SPC-01

Written specification

A documented behavior specification exists prior to development, defining intended use cases, in-scope and out-of-scope inputs, authorized tools, data scope, and conditions under which the agent must refuse or escalate.

The specification captures the agent's intended behavior in language a non-engineer can read and a tester can verify. It includes positive behavior (what the agent should do), negative behavior (what it should never do), escalation behavior (when and to whom it should hand off), and the conditions under which the specification itself should be revisited.

L3 · Operated

Specification exists for every production agent, is version-controlled, is current within an explicit time window, and is referenced by the operating runbook.

SPC-02

Capability evaluation suite

A capability evaluation suite is executed pre-deployment, with results recorded. Coverage includes functional accuracy on representative tasks, performance on known edge cases, and behavior on out-of-distribution inputs.

The evaluation suite exercises the agent against its specification before any production deployment. Coverage includes functional accuracy on representative tasks, performance on known edge cases, behavior on out-of-distribution inputs, and regression testing against previously discovered failures. Results are recorded and retained for audit.

L3 · Operated

Evaluation suite exists and is executed before every deployment; results are recorded with pass/fail criteria; coverage includes edge cases and out-of-distribution inputs; historical results are retained.

SPC-03

Adversarial assessment

An adversarial assessment (red team) is performed prior to initial deployment and after any material change. Minimum coverage: direct and indirect prompt injection, tool misuse, data exfiltration, role hijacking, jailbreak resistance, memory poisoning, and multi-agent escalation paths.

Red-team testing covers the full adversarial surface: direct and indirect prompt injection, tool misuse, data exfiltration paths, role hijacking, jailbreak resistance, memory poisoning (see INP-09), and where applicable, multi-agent escalation paths (see Domain 9). Findings are triaged, remediated or formally risk-accepted with executive sign-off, and the assessment is re-executed after material changes.

L3 · Operated

Red team assessment report exists for every production agent; findings have been triaged and dispositioned; the assessment has been re-executed within the documented cadence or after the most recent material change.

SPC-04

Policy alignment testing

Policy alignment testing confirms the agent refuses out-of-scope, prohibited, and adversarial requests in line with the Behavior Charter.

The agent is tested specifically against the negative-behavior and escalation-behavior sections of its Behavior Charter. Policy alignment testing confirms the agent refuses out-of-scope requests, rejects prohibited actions, and escalates appropriately when faced with adversarial inputs designed to push it outside its operating envelope.

L3 · Operated

Policy alignment test suite exists and covers all prohibited and escalation categories defined in the Behavior Charter; results are recorded; failures are tracked through remediation.

SPC-05

Deployment gate

A deployment gate prevents production release without documented sign-off from the technical owner, security, and compliance (where applicable).

No agent reaches production without passing through a documented gate that requires sign-off from the technical owner, security review, and compliance review where applicable. The gate is enforced by process or tooling — not by convention alone. Bypasses are logged and treated as incidents.

L3 · Operated

Deployment gate is enforced for all production deployments; sign-off records exist for the most recent deployment of each agent; no bypasses have occurred without documented incident follow-up.

SPC-06

Behavior baseline capture

A behavior baseline is captured at deployment — including response distributions, tool-invocation patterns, refusal rates, fairness metrics, and cost/latency profiles — to enable subsequent drift detection.

At the point of deployment, the agent's behavioral profile is captured: response distributions, tool-invocation patterns, refusal rates, fairness metrics under SPC-09, and cost/latency profiles. This baseline is the reference point for drift detection under MON-04 and is updated on every material change.

L3 · Operated

Baseline metrics are captured and stored for every production agent; baselines are referenced by the drift detection system; baselines have been updated after the most recent material change.

SPC-07

Versioned evaluation set

A versioned evaluation set is maintained per agent and re-executed on every material change. Results are retained as evidence.

Each agent has a versioned evaluation set that is maintained alongside the agent's specification. The evaluation set is re-executed on every material change, and results are retained as evidence. The evaluation set evolves as new failure modes are discovered, ensuring that previously identified risks remain covered.

L3 · Operated

Evaluation set is version-controlled; execution history shows re-runs on material changes; results are retained and accessible for audit; the set has been updated to cover newly discovered failure modes.

SPC-08

Known-unsafe inputs catalog

A known-unsafe inputs catalog is maintained organization-wide and tested against each agent prior to deployment.

The organization maintains a catalog of known-unsafe inputs — jailbreak prompts, injection patterns, adversarial payloads — that is tested against every agent before deployment. The catalog is updated as new attack patterns emerge and is shared across the organization to prevent duplication of effort.

L3 · Operated

Catalog exists and is maintained; the catalog has been tested against all production agents within the documented cadence; new entries are added as attack patterns are discovered or reported.

SPC-09

Fairness evaluation

Prior to deployment and after material change, the agent is evaluated for performance disparities and discriminatory outcomes across protected and operationally relevant groups, using representative test populations and documented metrics.

The agent is evaluated for systematic disparities in output quality, accuracy, refusal rates, and outcomes across protected categories and operationally relevant groups. Testing uses representative test populations and documented metrics (e.g., demographic parity, equalized odds, calibration). Findings are remediated, mitigated, or formally accepted with executive sign-off.

L3 · Operated

Fairness evaluation report exists for every production agent; documented metrics are used; findings have been dispositioned; the evaluation has been re-executed after the most recent material change.

Cross-references