# Agentic Security Control Matrix, Integration Guide

*The single, end-to-end guide for integrating the securitycontrols.ai dataset into your software
platform. Covers what you get, the architecture, the full data model, how to consume it (with code),
versioning, and licensing. Companion file: **`agentic-controls-full.json`** (the complete dataset for the current
release). The current release and live counts are shown below and are regenerated automatically with
every release. Nothing in this document is aspirational. If a capability is future work it is labelled as such.*

Live rendered result of this same data: **https://securitycontrols.ai**

---

## 1. What you get

A **governed, primary-sourced dataset** for securing autonomous AI agents, the complete content
that powers the live matrix, delivered as one versioned JSON document under a published schema.

**Current release: v1.2 (asOf 2026-06-25T02:04Z).** These figures regenerate automatically with every release.

| | this release |
|---|---|
| **Controls** | **51**, across 6 layers: Identity 6, Environment 10, Inter-Agent 8, Governance 11, Runtime 8, Continuous 8 |
| **Framework crosswalk** | every control mapped to up to **8 catalogs** (CSA AICM, CSA AISMM, NIST, ISO/IEC 42001 + EU AI Act, OWASP, OWASP AISVS, MITRE ATLAS, IMDA MGF), each cell carrying a **verification status** and a **fit grade** (direct / partial / adjacent / supporting) |
| **Primary-source references** | **75**, each with a resolvable `id` and URL |
| **Detection signals** | **17** controls carry a `detection_schema` (telemetry fields, baseline, alert), directional examples to adapt, not turnkey rules |
| **Response levers** | **24** controls carry a `response` (the operational lever) |
| **Coverage views** | OWASP Agentic Top 10 (10), CISA risk classes (5), AWS Scoping Matrix (6 dimensions + 4 scopes), threat scenarios (13) |
| **Other structures** | 3 named gaps (each with a compensating control + status), the RA-01 cross-layer enforcement pattern, a lifecycle view, a 15-control starter set |

Framework crosswalk coverage (mapped / verified / indicative):

| Catalog | Mapped | Verified | Indicative |
|---|---|---|---|
| NIST (AI RMF / 600-1 / COSAiS) | 50 | 50 | 0 |
| OWASP (ASI / LLM / NHI) | 50 | 38 | 12 |
| OWASP AISVS | 45 | 37 | 8 |
| CSA AISMM | 48 | 42 | 6 |
| ISO/IEC 42001 + EU AI Act | 47 | 45 | 2 |
| CSA AICM | 46 | 39 | 7 |
| IMDA MGF (Agentic AI) | 46 | 28 | 18 |
| MITRE ATLAS | 23 | 21 | 2 |

*Verified = confirmed against the primary source (existence and fit). Indicative = a plausible
mapping not yet source-confirmed. The verified/indicative split is deliberate and honest. We never
ship a fabricated identifier.*

## 2. Architecture: a data contract, not an API endpoint

securitycontrols.ai is **data-first and zero-runtime-dependency**. The product is not a service you
call. It is a **governed dataset** plus a deterministic build that renders it to a static, hardened
page. For an integrator this is a feature:

- **No live REST API, database, or auth server to integrate against today.** What you integrate
  against is the **data contract**: one JSON document, governed by a published JSON Schema, enforced
  by gates on every change. The whole corpus is one fetchable, versioned, schema-checked artifact , 
  no rate limits, no coupling to our infrastructure, works fully offline.

```
  Our side (source of truth)                    Your side (consumer)
  ----------------------------------------       ----------------------------------------
  data/agentic-controls.json  (51 controls)      load the JSON (one document)
        |                                                |
        |  gated on every change by:                     v
        |   1. validate.mjs   (shape/enums/cite-or-flag)  validate against our published
        |   2. audit-mappings.mjs (every ATLAS/OWASP      schema (draft-07) on your side too
        |      id checked vs a catalog snapshot)          |
        v                                                 v
  agentic-controls.schema.json  ---- same contract ---->  key your product to control ids
        |                                                 (your UI, control catalog, compliance
        v                                                  mapping, assessment engine, ...)
  build.mjs --> static matrix      build-blog.mjs --> blog
```

**Two integrity guarantees you inherit for free:**
1. **Schema-validated.** Every change is gated by `validate.mjs` (shape, enums, and a cite-or-flag
   rule: every implementation/validation claim resolves to a reference or is explicitly flagged).
2. **Identifier-verified.** Every MITRE ATLAS (technique, mitigation, case study), OWASP, and OWASP
   AISVS identifier in the crosswalk is checked against a catalog snapshot at build time
   (`audit-mappings.mjs`). an id that does not resolve fails
   the build. So a mapping you consume cannot silently reference a nonexistent technique.

**The integration key is the control `id`** (e.g. `IA-01`). Key your own product data to these stable
ids. Ids are append-only across versions (we add controls, we do not renumber existing ones).

## 3. The data model (full field reference)

### 3.1 Top-level keys

| Key | What it is |
|---|---|
| `meta` | `title`, `version`, `asOf`, `agentDefinition`, `baseline` (the 15 starter-set ids), `baselineNote`, `thesis`, `source_editions` (the pinned edition of each crosswalked catalog — what "verified against" means this release), `adjacent_domains` (planned multi-domain sets, see §6), `starAiNote` (defines the `star_ai` control tag), `note` |
| `controls` | the 51 control records (detailed below) |
| `references` | primary sources (live count in the stats table above): `{id, title, url, type, date}`, every `sources[]` / `ref` resolves here |
| `layers` | the 6 layers: `{key, num, name, blurb, plain, color, defaultPlane}` |
| `planes` | control / data / both / lifecycle, the organising lens |
| `gaps` | 3 named gaps: `{id, title, plain, desc, teams, compensating, status}` |
| `patterns` | RA-01 Agent Runtime Enforcement Plane (cross-layer): `{id, title, plain, desc, controls[]}` |
| `asi_coverage` | OWASP Agentic Top 10 → controls |
| `cisa_coverage` | CISA risk classes → controls |
| `aws_coverage` | AWS Scoping Matrix 6 dimensions → controls |
| `aws_scopes` | AWS 4 agency scopes → controls (aligned to risk-driver tiers) |
| `threat_scenarios` | concrete attack stories → controls (live count in the stats table above) |
| `lifecycle` | the 4-stage operational lifecycle view |
| `implementerStatus` | per-implementer status (standard / product / preview / open-source / research / guidance) |
| `roadmap` | 3 future-feature stubs: `{id, title, detail}` (e.g. product-feature-to-control map) — planned, not shipped |

### 3.2 Per-control record

| Field | Type | What it gives a consumer |
|---|---|---|
| `id`, `layer`, `plane` | string | stable key + taxonomy |
| `name`, `plain` | string | a precise technical label and a plain-language one-liner |
| `threat` | `{tags[], desc}` | the threat it stops, tagged to OWASP ASI/NHI ids |
| `standard` | string[] | the standards/protocols behind it |
| `mappings` | object | crosswalk: `{aicm, aismm, nist, iso, owasp, aisvs, mitre, mgf}`, each `{value, status, fit?, evidence?}` (status = verified / indicative; `forthcoming` is a reserved value, not currently used). Keys are present only where a mapping exists. `fit` (direct / partial / adjacent / supporting) grades how strongly the source matches the control, separate from `status`. The optional `evidence` is `{ref, section, rationale, verified_on?}` — `ref` is a `references[]` id, `section` the cited clause, `rationale` a one-line why, `verified_on` the check date (verified cells only). |
| `enforcement_point` | string | where the control is actually enforced architecturally (on all 51) |
| `tiers` | string[] | risk drivers that make it matter more: autonomy / external-reach / irreversibility / data-sensitivity (on all 51) |
| `readiness` | string? | deployment maturity — deployable / emerging / research (on the 10 controls where readiness is the salient question; this is a different set from the thesis controls below) |
| `matrix_thesis`, `thesis_type` | bool / string? | flags this matrix's own positions (compensating / elevated / frontier), not attributed to a standards body |
| `implementers`, `frameworks` | string[] | who builds it (vendor-neutral tracking) and the framework tokens it maps to. **Note:** `frameworks` is derived from `mappings` at build time, see §5. |
| `sources` | string[] | reference ids (resolve in `references`) |
| `implementation` | `{pattern, steps[], anti_patterns[]}` | how to deploy it |
| `validation` | `{design_check[], runtime_test[], evidence[]}` | how to prove it holds. Each entry is cite-or-flagged with a `ref` (or `unverified:true`) |
| `lenses` | `{engineering, detection, red_team, grc, secops}` | the same control through 5 role lenses |
| `maturity` | `{current, target}` | a scoring axis for self-assessment |
| `detection_schema` | `{telemetry[], baseline, alert}`? | on the 17 detection-bearing controls: a directional SIEM signal scaffold (illustrative, adapt before use) |
| `response` | `{lever, detail}`? | on the 23 controls with one: the operational lever |
| `coverage_note` | string | where present (10 controls), links to a gap id where the control is bounded by an open gap; empty otherwise |
| `star_ai` | bool? | `true` on the 14 controls that map to an AI-Specific AICM v1.1 control (the CSA STAR AI examinable set, distinct from legacy CCM-derived controls). Re-derived cell-by-cell against AICM v1.1. See `meta.starAiNote`. Thesis controls are not claimed as STAR-examinable. |

The authoritative contract is the published **`agentic-controls.schema.json`** (JSON Schema). Validate
against it on your side too. Additive changes are safe: `additionalProperties: true` at the top level
means new fields never break a conforming consumer.

## 4. How to integrate (patterns + code)

The integration key is the control `id`. Four concrete consume patterns:

**A. Mirror the catalog.** Render our controls + crosswalk inside your console so your customers see
the matrix in your tool.

**B. Map your product to controls.** For each of your features, record which control `id`s it
addresses. Now you can show coverage against a neutral, primary-sourced control set.

**C. Drive assessment.** Use the `maturity` axis and `validation` checks to power a readiness or
gap-assessment view, keyed to the same ids.

**D. Export detection content.** Pull `detection_schema` from the 17 detection-bearing controls into
your SIEM as the basis for Sigma / OpenTelemetry / KQL rules. Each detection also carries its MITRE
ATLAS context (the techniques it detects, the ATLAS mitigations it implements, and related case
studies) from the control's `mappings.mitre` and the threat-scenario `atlas` references, so a signal
ties back to the adversary technique and the named defensive mitigation.

> **Detection content is directional.** The `detection_schema` and `response` fields are illustrative
> examples and placeholders that show the shape of a detection, not production-ready rules to deploy
> out of the box. Adapt, validate, and tune every field against your own environment and telemetry
> before any use. A deeper, implementation-ready detection resource is planned, treat what is here as
> an early scaffold, not the finished library.

```javascript
// Load + use (Node / browser). The full export nests the data under .dataset.
const pkg = await fetch('agentic-controls-full.json').then(r => r.json());
const D = pkg.dataset;

// A control by id
const byId = Object.fromEntries(D.controls.map(c => [c.id, c]));
byId['IA-01'].mappings.nist;          // { value: 'AI RMF: Manage', status: 'verified' }

// B. coverage: which of MY features cover which controls
const myFeatureCoverage = { 'my-iam-module': ['IA-01','IA-02','IA-04'] };

// D. detection pack for the SIEM team (with ATLAS context per detection)
const csFor = id => [...new Set((D.threat_scenarios || [])
  .filter(s => s.atlas && s.controls.includes(id)).flatMap(s => s.atlas))];
const detectionPack = D.controls
  .filter(c => c.detection_schema)
  .map(c => {
    const mv = c.mappings.mitre?.value || '';
    return { id: c.id, name: c.name, ...c.detection_schema, response: c.response || null,
      atlas: { techniques: mv.match(/AML\.T\d+(?:\.\d+)?/g) || [],
               mitigations: mv.match(/AML\.M\d+/g) || [], case_studies: csFor(c.id) } };
  });
```

```python
# Python consumer
import json
D = json.load(open('agentic-controls-full.json'))['dataset']
by_id = {c['id']: c for c in D['controls']}

# controls that map to a given framework, with status
def controls_for(framework_key):
    return [(c['id'], c['mappings'][framework_key]['status'])
            for c in D['controls'] if c['mappings'].get(framework_key)]
controls_for('mgf')   # [('IA-01','verified'), ...]
```

## 5. Two derived views you must replicate correctly

Some views are computed from the source at build time. If you re-implement them, use the same
derivation so your counts match ours:

- **Framework filter / `frameworks[]`** is derived from `mappings` (plus AWS coverage), not
  hand-maintained. A control "maps to NIST" iff `mappings.nist` exists. Do not trust a stale
  `frameworks[]` array as the source of truth for filtering, derive it:
  ```javascript
  const COLS = {aicm:'CSA AICM', aismm:'CSA AISMM', nist:'NIST', iso:'ISO / Reg',
                owasp:'OWASP', aisvs:'OWASP AISVS', mitre:'MITRE ATLAS', mgf:'IMDA MGF'};
  const frameworksOf = c => Object.keys(COLS).filter(k => c.mappings[k]).map(k => COLS[k]);
  ```
- **AWS per-control dimension** is derived by inverting `aws_coverage` (dimension → controls), not
  stored per control. Build a `controlId → [dimensions]` map from `aws_coverage`.

## 6. Versioning and updates

- `meta.version` + `meta.asOf` identify the snapshot you are on. v1.2 is current (2026-06-24).
- **Additive by contract.** New controls/fields/mappings are added. Existing control ids are never
  renumbered. `additionalProperties: true` keeps additive changes non-breaking.
- **Multi-domain extensibility.** This is the *security* domain of a planned multi-domain control
  view. `meta.adjacent_domains` lists the planned adjacent non-security sets (privacy, financial,
  model-eval, reliability) as `planned`, and the schema reserves an optional per-control
  `cross_domain` link so those sets can be crosswalked from a larger view later without a breaking
  change. Neither is populated yet; key any cross-domain integration to the control `id`.
- **Change record.** `CORRECTIONS.md` is the human-readable changelog (what changed, what was
  corrected, and why). Mappings are periodically re-audited against the source catalogs. The
  source-verifier gate prevents nonexistent identifiers from regressing in.
- **Update cadence.** The dataset is refreshed when a standard revises, a new framework column is
  added (mapped indicative first, never shipped verified), a control is reworded, or vendor/
  implementer status moves.

## 7. What is not included today (so nothing is oversold)

- **A live queryable API** (filter/search/auth/per-tenant) does **not** ship today. It is a
  buildable extension on the same dataset, not a current capability. A staged path exists, a static
  read-API (versioned JSON endpoints, no database) first, then an authenticated app, and can be
  scoped as new work if you need it.
- **Accounts / saved server-side state** is not provided. The live tool keeps assessments in the
  browser (localStorage + JSON export). Server-side state is the same buildable extension.

## 8. Licensing and what a commercial license grants

The dataset is **CC BY-NC 4.0**: free for non-commercial use with attribution. **Embedding this
dataset in a commercial product, using it to deliver paid assessments or tools, or any
revenue-generating use requires a written RiskOne commercial license.** A commercial license grants
the right to integrate and redistribute the dataset inside your product, with update access to new
versions, under terms agreed with RiskOne.

The companion **`agentic-controls-full.json`** is the complete dataset (all 51 controls and
every field) provided for evaluation and, on license, for integration.

**Contact:** aisecurity@risk.one

---

## 9. The Apeiris network (cross-domain)

securitycontrols.ai is one verifier in the **Apeiris** network. Each domain owns a distinct slice of
AI assurance and composes with the others through a shared URI scheme, so a claim made in one domain
can reference a control in another **without duplicating it**. This section is a forward-looking note:
two domains are live today, the rest are reserved placeholders. The machine-readable version is in the
dataset export under `dataset.network`.

**Live sister domain — Model Verifier.** [modelverifier.ai](https://modelverifier.ai/) owns model and
system fitness (evaluation, validation, behavioral measurement). Its integration package and the
matching cross-domain contract are at [modelverifier.ai/integrate](https://modelverifier.ai/integrate);
it references our controls as `apeiris://security/controls/<ID>` and we reference its controls as
`apeiris://model/controls/<ID>` (see §9.3 for the linked pairs).

**URI scheme.** `apeiris://<domain>/controls/<ID>`. A reference resolves to that domain's host and the
control record in its integration export. For example `apeiris://security/controls/IA-01` resolves to
this matrix (host `securitycontrols.ai`); modelverifier.ai references our controls the same way, and we
reference theirs as `apeiris://model/controls/<ID>`. Reserved domains do not resolve yet.

**Scope separation** (why the domains compose instead of overlapping):

| Domain | Host | Owns | Status |
|---|---|---|---|
| `security` | **securitycontrols.ai** | Runtime security & enforcement for agents: identity, containment, protocol, governance, monitoring, assurance | **active** (this site) |
| `model` | **modelverifier.ai** | Pre-deployment model/system fitness: evaluation, validation, behavioral measurement | **active** |
| `identity` | identitycontrols.ai | Human & non-human identity controls | reserved |
| `agentic` | agenticverifier.ai | Agent behavior verification | reserved |
| `compliance` | complianceverifier.ai | Regulatory compliance verification | reserved |
| `privacy` | privacyverifier.ai | Privacy controls & verification | reserved |

**Parent.** Apeiris (`apeiris.ai` / `apeiris.com`, planned) is the parent and commercial-licensing
entity. The enforcement *platform* is built separately from these control-definition matrices — the
matrices define *what must hold*; the platform is *where it is enforced*.

**Why this matters for integration.** Key your product to the stable `apeiris://` ids and a finding can
travel across domains: a model-evaluation claim in `model` can cite the `security` runtime control that
must back it, and a single record never has to be maintained in two places. Today, treat `security` and
`model` as live and the rest as reserved namespace.

### 9.1 Per-control cross-domain links (`cross_domain`)

Controls whose enforcement depends on, mirrors, or composes with a model-assurance control carry a
machine-readable `cross_domain` array (in the dataset export and rendered on the card as "Across the
network"):

```json
"cross_domain": [
  { "domain": "model", "uri": "apeiris://model/controls/LI-02",
    "id": "LI-02", "name": "Model Provenance Chain", "rel": "depends-on" }
]
```

`rel` is one of `depends-on` (our control relies on the model-domain result), `mirrors` (the same
requirement on the other side of the boundary), or `composes-with` (complementary). 13 controls are
linked today — mostly the Continuous Assurance layer plus selected runtime/governance controls
(e.g. `AS-06 → LI-02/LI-05`, `PT-03 → LI-03`, `AS-01 → EV-04`, `GV-01 → OA-02`, `GV-02 → CR-02`,
`RT-02 → BH-06`, `GV-05 → OA-04`, `EC-05 → BH-07`).

### 9.2 Mapping across many models (the multi-model contract)

A security control is asserted **once per agent**; model fitness is asserted **once per model**. A
single agent typically runs on **many** model artifacts (a base model, fine-tunes, merges, LoRA
adapters, and per-task models), so the binding is one-to-many. This is the part a runtime owner must
get right, and it is where we specify at least the model domain's standard.

Bind each model the agent can load by its **content-addressed identity** (the model domain's `LI-01`
hash), and attach the relevant model-domain evaluation per model. A security control's posture is then
the **composition** over every model in scope — it holds only if it holds for each:

```json
{
  "agent": "apeiris://security/agents/payments-bot",
  "security_control": "apeiris://security/controls/AS-06",   // load only verified weights
  "applies_across_models": [
    { "model_id": "sha256:9f8c…", "role": "base",
      "model_eval": "apeiris://model/controls/LI-02", "decision": "pass" },
    { "model_id": "sha256:2b4a…", "role": "fine-tune",
      "model_eval": "apeiris://model/controls/LI-02", "decision": "pass" },
    { "model_id": "sha256:77de…", "role": "adapter",
      "model_eval": "apeiris://model/controls/LI-05", "decision": "inconclusive" }
  ],
  "composed_decision": "fail"   // weakest-link: one inconclusive/fail fails the control
}
```

Rules of the contract:
- **Key on the model content hash (`LI-01`), never a display name** — fine-tunes and merges share names
  but differ by weights; the hash is the only safe join key.
- **Composition is weakest-link by default** — a security control that ranges over N models passes only
  if every in-scope model's required model-domain control passes; surface which model failed.
- **Provenance fans out** — `AS-06 → LI-02` must be evaluated for the base model *and* every fine-tune,
  merge, and adapter in the lineage, not just the top-level artifact (the model domain's provenance
  graph is queryable for "all models derived from base X").
- **Per-model, not per-agent, expiry** — re-validation cadence follows each model's eval expiry, so
  swapping one adapter re-opens only that model's leg, not the whole assessment.

This makes a runtime security posture composable over an arbitrary fleet of models while keeping each
model's fitness owned by `model` — one agent, many models, no duplicated assertions.

---

### 9.3 Resolution and reciprocal links

**Resolution.** An `apeiris://security/controls/<ID>` reference resolves to this matrix at
`https://securitycontrols.ai/#<ID>` (the page deep-links and opens that control), and to its record in
`agentic-controls-full.json` keyed by `id`. The model domain resolves the same way at its own host.

**Reciprocal links (live both ways).** Our 14 links to the model domain and the model domain's links
back to us are both published, so a finding composes from either side. The inverse set the model domain
carries:

| Model-domain control | Should link back to | rel |
|---|---|---|
| `apeiris://model/controls/LI-02` (Model Provenance Chain) | `apeiris://security/controls/AS-06` | depends-on |
| `apeiris://model/controls/LI-05` (Training Data Lineage Pointer) | `apeiris://security/controls/AS-06` | depends-on |
| `apeiris://model/controls/LI-03` (Supply Chain Integrity) | `apeiris://security/controls/PT-03` | mirrors |
| `apeiris://model/controls/EV-04` (Adversarial Red-Team Testing) | `apeiris://security/controls/AS-01` | composes-with |
| `apeiris://model/controls/EV-01` (Pre-Deployment Evaluation Gate) | `apeiris://security/controls/AS-03` | composes-with |
| `apeiris://model/controls/EV-02` (Fitness/Safety/Reliability/Policy Eval) | `apeiris://security/controls/AS-05` | composes-with |
| `apeiris://model/controls/BH-04` (Behavioral Boundary Performance Testing) | `apeiris://security/controls/AS-07` | composes-with |
| `apeiris://model/controls/BH-06` (Injection-Resistance Evaluation) | `apeiris://security/controls/RT-02` | composes-with |
| `apeiris://model/controls/BH-07` (Resource and Cost Anomaly Monitoring) | `apeiris://security/controls/EC-05` | composes-with |
| `apeiris://model/controls/BH-09` (Synthetic-Content Provenance/Disclosure) | `apeiris://security/controls/GV-07` | composes-with |
| `apeiris://model/controls/OA-02` (Meaningful Human Oversight) | `apeiris://security/controls/GV-01` | composes-with |
| `apeiris://model/controls/OA-04` (Delegated Autonomy Tier Governance) | `apeiris://security/controls/GV-05` | composes-with |
| `apeiris://model/controls/CR-02` (Model Evidence Archive and Audit Trail) | `apeiris://security/controls/GV-02` | mirrors |
| `apeiris://model/controls/CR-01` (Continuous Production Monitoring) | `apeiris://security/controls/RT-04` | composes-with |

---

## Appendix A, the full control set (51)

*`[core]` marks the 15-control starter set: the minimum we would not run any autonomous agent without.*

**Identity & Authority**
- IA-01 Give every agent its own distinct identity, never a shared or human login [core]
- IA-02 Hand out short-lived, task-scoped keys (no long-lived secrets) [core]
- IA-03 Act on the user's behalf with explicit approval for sensitive steps
- IA-04 Check permission continuously at run time, not just once at login
- IA-05 Find and inventory every agent, surface the shadow ones
- IA-06 Bind a signed, end-to-end provenance chain to every agent action
**Environment & Containment**
- EC-01 Run the agent in a sandbox, from process isolation up to micro-VMs [core]
- EC-02 Filter the agent's outbound network traffic [core]
- EC-03 Keep memory short-lived, and validate anything written to it
- EC-04 Limit filesystem and tool access to the bare minimum [core]
- EC-05 Cap spend and resource use, stop denial-of-wallet
- EC-06 Contain runaway loops and over-reach (least-agency)
- EC-07 Trust-rank retrieved content before it enters the agent's context
- EC-08 Keep secrets out of the prompt and context [core]
- EC-09 Treat the workspace and its config and hooks as untrusted
- EC-10 Verify trigger provenance and admit autonomous runs
**Inter-Agent & Tool Protocols**
- PT-01 Authenticate and sign agent-to-agent communication
- PT-02 Authorize tool calls and govern the MCP server registry
- PT-03 Verify skill/tool manifest integrity and sign the supply chain
- PT-04 Validate tool input/output, treat tool results as untrusted [core]
- PT-05 Encode and validate the agent's own output before it reaches other systems
- PT-06 Sanitize model-generated tool parameters, not just the schema
- PT-07 Verify tool descriptions for hidden instructions (description injection)
- PT-08 Enforce an instruction hierarchy so tool output cannot give the agent orders [core]
**Governance & Human-in-the-Loop**
- GV-01 Require a human hard-stop for irreversible actions [core]
- GV-02 Keep an immutable, tamper-evident audit trail of what the agent did [core]
- GV-03 Define multi-agent authority and conflict resolution explicitly
- GV-04 Enforce policy as code at run time, in the request path
- GV-05 Run an AI management system and tier agents by their autonomy
- GV-06 Cap the rate and volume of irreversible actions
- GV-07 Protect humans from being deceived by an agent
- GV-08 Make high-impact actions transactional, atomic, idempotent, state-checked
- GV-09 Anchor a named business owner to every agent (accountability) [core]
- GV-10 Enable end-user responsibility and guard against automation bias
- GV-11 Plan recovery and compensation for actions the agent already committed
**Runtime Supervision & Detection**
- RT-01 Capture OS-level telemetry of what the agent actually does [core]
- RT-02 Detect direct and indirect prompt injection at every input and output [core]
- RT-03 Supervise the agent's reasoning and check it matches its actions
- RT-04 Detect anomalies and trigger pause, kill switch, or containment [core]
- RT-05 Apply data-loss prevention to agent egress and interactions
- RT-06 Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration
- RT-07 Detect multi-agent collusion and covert channels
- RT-08 Monitor latent and representation-level signals, not just visible reasoning
**Continuous Assurance**
- AS-01 Adversarially red-team and evaluate the agent before launch [core]
- AS-02 Statically analyze agent skills and manifests in CI
- AS-03 Gate releases on continuous adversarial validation
- AS-04 Run a bug-bounty / vulnerability reward program for agentic abuse
- AS-05 Study frontier offensive capability before public release
- AS-06 Verify model-weights and training-data provenance before load
- AS-07 Verify a skill does what it declares (behavioral integrity)
- AS-08 Harden and assure the security control plane as tier-zero infrastructure

## Appendix B, files in this package

All are served publicly at `https://securitycontrols.ai/integration/`, CORS-enabled, regenerated every release.

- **`agentic-controls-full.json`** — the complete dataset (manifest + all 51 controls under `.dataset`).
- **`agentic-controls.schema.json`** — the JSON Schema (draft-07), the formal shape contract, now public.
- **`release-manifest.json`** — `content_sha256` of the full export, `generated_at`, `version`,
  `dataset_as_of`, and counts (`controls`, `sources`, `gaps`, `profiles`, `vendor_features`) plus a
  `warning_count` (indicative mappings + unverified validation entries, with a note on what each means).
- **`sources.json`** — the full primary-source references catalog (every `sources[]` / `ref` resolves here).
- **`vendor-coverage.json`** / **`vendor-coverage.csv`** — the vendor feature → control coverage chart.
- **`INTEGRATION-GUIDE.md`** — this document.
- Live rendered reference: https://securitycontrols.ai

**Verify the release:** fetch `release-manifest.json`, then check `content_sha256` equals the SHA-256 of
`agentic-controls-full.json` as served. When `signature_alg` is `ed25519`, the manifest also carries a
detached Ed25519 `signature` over `content_sha256`; verify it with the public key at `public_key_url`
(`/.well-known/apeiris-release.pub`). Unsigned builds set `signature: null` and say so in
`signature_note`. The schema, full dataset, and manifest are linked from the site footer.

*Operators: to sign releases, generate an Ed25519 key (`openssl genpkey -algorithm ed25519 -out
apeiris-release.pem`), store the private PEM as the CI secret `APEIRIS_RELEASE_PRIVATE_KEY_PEM`, and the
build publishes the derived public key automatically. Keep the private key out of the repo.*