COMPEL Specialization — AITM-AAG: Agentic AI Governance Associate Article 14 of 14
Definition. The Agent Governance Pack is the named artifact that, per agent, aggregates the outputs of every prior article in this credential into a single maintained document bound to the agent registry entry. The pack is not a one-time deliverable. It is a living document — updated on change events, reviewed on cadence, and consulted by incident responders, internal auditors, and regulators. An agent in production without a current pack is, from a governance perspective, unregistered. From a regulatory perspective in EU high-risk contexts, it is an Article 26 compliance gap.
Pack composition — one section per prior article
The pack has thirteen sections, each carrying the output of the corresponding prior article in this credential plus a section 14 that synthesises the set.
| Section | Content | Source article |
|---|---|---|
| 1. Definition | What this agent is, in one paragraph | Article 1 |
| 2. Inventory record | Registry entry: identity, version, architectural pattern, owner | Article 2 |
| 3. Autonomy classification | Level and the four criteria | Article 3 |
| 4. Authority chain | Five-component chain sentence and memo | Article 4 |
| 5. Oversight regime | Four-mode design with operator roles and signal specs | Article 5 |
| 6. Tool-use governance | Registry, permissions, caps, sanitisation, audit | Article 6 |
| 7. Memory policy | Layers, scope, retention, access, poisoning defence | Article 7 |
| 8. Multi-agent posture | Topology (if any), A2A protocol, coordinator | Article 8 |
| 9. Risk register | Categories live for this agent with controls and owners | Article 9 |
| 10. Observability plan | Layers instrumented, audit schema, SIEM integration | Article 10 |
| 11. Containment and incident playbooks | Kill-switch wiring, containment boundaries, incident classes with playbooks | Article 11 |
| 12. Regulatory map | Applicable articles, clauses, controls implemented, evidence location | Article 12 |
| 13. Cross-organisational posture | Dependencies, counterparty contracts, supply-chain dependencies | Article 13 |
| 14. Pack metadata | Version, authors, reviewers, sign-off dates, change log | This article |
An agent’s pack has all thirteen content sections populated. A section that does not apply (for example, Section 8 for a non-multi-agent system, or Section 13 for a purely internal agent) is explicitly marked “not applicable” with a reason; it is not left blank.
The living-document principle
The pack is not a deliverable that ships with the agent and freezes. Nine change events trigger a pack update.
| Change event | Trigger in pack |
|---|---|
| Model swap | Sections 3, 6 |
| Tool addition or removal | Sections 3, 6, 9 |
| Memory-scope change | Sections 3, 7 |
| Human-in-the-loop cadence change | Sections 3, 5 |
| New integration (upstream or downstream) | Sections 8, 13 |
| New high-risk regulatory classification | Section 12 |
| Incident | All sections, as the incident review dictates |
| Scheduled review (cadence) | All sections, quality check |
| Owner change | Section 2, Section 14 |
Every change event is logged in Section 14 with date, actor (by role), and summary. The pack has a version number; changes increment it.
Pack production workflow
Producing the first pack for an agent follows a sequence that mirrors this credential’s articles.
- Discovery (Article 2). The agent is found, identified, given a stable identifier.
- Definition (Article 1). One paragraph on what the agent is and what it does.
- Classification (Article 3). Level assignment with the four criteria documented.
- Authority chain (Article 4). Chain sentence and memo.
- Oversight (Article 5). Mode assignment per action class, operator competency, signal specs.
- Tool-use (Article 6). Per-tool specifications.
- Memory (Article 7). Layers, policies, defences.
- MAS (Article 8). Only if applicable; otherwise “not applicable” with reason.
- Risk register (Article 9). Categories, controls, owners.
- Observability (Article 10). Layers, schema, integrations.
- Containment and incident (Article 11). Kill-switch and playbooks.
- Regulatory map (Article 12). Article-to-control mapping.
- Cross-organisational (Article 13). Dependencies and contracts.
- Synthesis and sign-off (this article). Metadata, version, reviewers, approval.
The workflow is serial by design. Each section depends on the ones before it. Skipping ahead produces a pack with internal inconsistencies — an oversight regime that does not match the autonomy level, a tool registry that exceeds the authority chain, a risk register that doesn’t cover the tool surface.
Internal consistency checks
Before sign-off, the pack is reviewed for internal consistency. Ten checks are standing rules.
- Autonomy level (Section 3) matches the oversight-mode mix (Section 5).
- Tool registry (Section 6) is within the authority chain’s action scope (Section 4).
- Memory policy (Section 7) references the tools that can write to memory (Section 6).
- MAS topology (Section 8) has coordinator and per-agent authority chains that match Section 4.
- Risk register (Section 9) covers every category relevant to the tool surface and memory policy.
- Observability (Section 10) instruments every signal the oversight regime (Section 5) depends on.
- Kill-switch (Section 11) is exercisable by the identity named in Section 4’s authority chain.
- Regulatory map (Section 12) covers every article applicable to the agent’s classification (including derivative Annex III obligations if any).
- Cross-organisational posture (Section 13) aligns with the tool registry (Section 6) and MAS posture (Section 8).
- Metadata (Section 14) names the current owner, reviewer, and sign-off dates.
Any failed check is a pre-sign-off fix. A pack that ships with an unresolved consistency failure ships with a known governance gap.
Sign-off
The pack has multiple sign-offs. The exact set depends on organisational structure, but a working pattern is:
- Agent owner (Section 2). Accountable for the agent.
- Governance function. Reviews consistency and policy alignment.
- Security function. Reviews Sections 6, 7, 9, 10, 11 against security controls.
- Legal / Privacy function. Reviews Sections 4, 7, 12, 13 against legal and data-protection obligations.
- Executive sponsor (for high-risk systems). Signs off deployment decisions beyond technical adequacy.
Sign-offs are logged in Section 14. A sign-off is dated and bound to a specific pack version.
Pack-to-registry linkage
The agent registry (Article 2) holds the short record; the pack holds the long record. The two are linked bidirectionally:
- The registry record includes a pointer to the current pack version.
- The pack’s Section 2 (inventory record) mirrors the registry’s core fields.
- A change in one triggers an update to the other.
The link is a governance control. An agent appearing in the registry without a pack, or a pack referring to an agent not in the registry, is an inconsistency that the monthly governance review catches.
The pack in operation
The pack’s value becomes visible in four operating situations.
Situation 1 — incident
The incident responder opens the pack. Sections 9 (risk), 10 (observability), and 11 (incident playbooks) are the responder’s working substrate. The playbook names the detection signals, the containment actions, the diagnostic steps, and the remediation owners. The response time is shorter because the document exists.
Situation 2 — regulatory or audit review
A regulator or internal auditor asks for the governance file for the agent. The pack is the file. The regulatory map (Section 12) translates the regulator’s article-level question into the organisation’s control-level answer. The evidence location fields tell the regulator where to find the underlying artifacts (logs, approvals, test results).
Situation 3 — change
A change event is proposed — a model swap, a new tool, a cadence change. The pack is the starting point for the change-impact analysis. Sections affected are identified; reviewers determined; the change either proceeds with the updated pack or is revised until it does.
Situation 4 — retirement
An agent is being retired. The pack’s retirement plan (a sub-section of Section 14 prepared before retirement) names what happens to memory (Section 7), to shared knowledge (Sections 7–8), to audit records (Section 10), to cross-organisational dependencies (Section 13). Retirement is executed against the plan and recorded in the pack’s final version.
Two real-world anchors for the pack concept
Shavit et al., “Practices for Governing Agentic AI Systems” (OpenAI, 2024)
The Shavit et al. paper (covered in Article 1 of this credential) is the closest public parallel to the Agent Governance Pack at a conceptual level. The paper names practices that, assembled, resemble a pack structure. The governance analyst reads the paper as one voice; the COMPEL pack is this credential’s synthesis, not a copy. Source: https://cdn.openai.com/papers/practices-for-governing-agentic-ai-systems.pdf.
NIST AI Safety Institute (AISI) agentic work
The U.S. NIST AI Safety Institute (AISI), established in 2024, is producing guidance that addresses agentic AI risk management at the national level. Source: https://www.nist.gov/aisi. The specialist uses AISI output as one input when updating the pack’s regulatory map, recognising that its outputs will continue to develop and that the pack’s quarterly review incorporates new guidance.
Learning outcomes — confirm
A specialist who completes this article should be able to:
- Name the fourteen pack sections and map each to the source article in this credential.
- List the nine change events that trigger pack updates.
- Execute the ten-check consistency review on a described pack draft.
- Produce an Agent Governance Pack outline for a described agent deployment, populated to Section 14.
Cross-references
EATE-Level-3/M3.4-Art11-Agentic-AI-Governance-Architecture-Delegation-Authority-and-Accountability.md— expert delegation and accountability architecture.- Every prior article in this credential (Articles 1–13).
Diagrams
- HubSpokeDiagram — Agent Governance Pack hub with the thirteen content section spokes plus Section 14 metadata.
- BridgeDiagram — agent registry ↔ governance pack bidirectional linkage.
Quality rubric — self-assessment
| Dimension | Self-score (of 10) |
|---|---|
| Technical accuracy (pack sections map cleanly to source articles) | 10 |
| Technology neutrality (no vendor privileged) | 10 |
| Real-world examples ≥2 (Shavit et al., NIST AISI) | 10 |
| AI-fingerprint patterns | 9 |
| Cross-reference fidelity | 10 |
| Word count (target 2,500 ± 10%) | 10 |
| Weighted total | 92 / 100 |