WAF-AGN-100 – Agent Debt Register
Description
Known agent limitations must be documented in an Agent Debt Register. Limitations include: knowledge cutoff, tool availability, accuracy limitations, edge cases, and failure modes. The register must be reviewed quarterly with improvement plans.
Rationale
Undocumented agent limitations create several problems:
Unexpected failures: Agents may fail in ways that are not anticipated.
Compliance gaps: Regulators may require knowledge of system limitations.
User confusion: Users may not understand agent limitations and expect incorrect capabilities.
Difficulty debugging: When agents fail, unknown limitations make root cause analysis harder.
No improvement tracking: Cannot measure progress if limitations aren’t tracked.
Requirements
-
Agent Debt Register must exist documenting all known limitations
-
Each limitation must include: description, impact assessment, priority, target date, owner
-
Register must be reviewed quarterly with improvement plans
-
Limitations must be categorized: knowledge, tool, accuracy, edge cases, failure modes
-
Improvement plans must include concrete steps and responsible parties
Implementation Guidance
-
Create register: Use document, database, or repository to document limitations
-
Categorize limitations: Group by type (knowledge cutoff, tool gaps, accuracy, etc.)
-
Assign ownership: Each limitation should have a responsible party
-
Set priorities: Use high/medium/low for ordering improvement work
-
Schedule reviews: Quarterly reviews with documented outcomes
-
Track progress: Link improvements to development backlogs
Maturity Levels
| Level | Name | Criteria |
|---|---|---|
1 |
No Register |
No documentation of agent limitations. Unknown risks. |
2 |
Ad-hoc Documentation |
Some limitations documented. No formal process. |
3 |
Formal Register |
Agent Debt Register maintained. Quarterly reviews. |
4 |
Automated Tracking |
Limitations linked to issue tracking. Progress dashboards. |
5 |
Predictive Debt |
AI predicts potential limitations before they occur. |
Evidence
| Type | Required | Description |
|---|---|---|
IaC |
✅ Required |
Agent Debt Register file (document, database schema, repository). |
Config |
✅ Required |
Review schedule configuration, improvement plan templates. |
Process |
✅ Required |
Quarterly review meeting notes, improvement progress reports. |
Governance |
✅ Required |
Agent Debt Register policy defining requirements and procedures. |
Regulatory Mapping
| Framework | Controls |
|---|---|
ISO 27001:2022 |
A.8.1 – Information security roles and responsibilities; A.8.2 – Privileged access rights |
NIST SP 800-53 |
RA-5 – Vulnerability scanning; SI-4 – Information system monitoring |
NIST CSF 2.0 |
DE.CM – Continuous monitoring; DE.AE – Anomalies and events |
GDPR |
Art. 32 – Security of processing; Art. 5(1)(f) – Integrity and confidentiality |
PCI DSS v4.0 |
Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices |
TISAX |
Information security – Monitoring and logging |
ANSSI SecNumCloud |
Domain – Logging and monitoring |
BIO |
BIO – Logboekhouding en monitoring |
ENS High |
op.exp.6 – Gestión de cambios |
UK NCSC CAF |
A4 – Policy and assurance |
FedRAMP |
RA-5, SI-4 (Moderate baseline) |
CMMC 2.0 |
RA.L2-3.8.1 – Vulnerability scanning |
IT-Grundschutz |
ORP.1 – Informationstechnisch-related Angriffsschutz |
IRAP |
ISM – Logging and monitoring |
CCCS PBMM |
RA-5 – Vulnerability scanning |
MAS TRM |
Ch.9 – Change management |
ISMAP |
Monitoring and logging controls |
FISC |
Technical measures – Logging and monitoring |
AWS Well-Architected Framework |
Security Pillar – System limits; Reliability Pillar – Failure modes |
Google Cloud Architecture Framework |
Reliability – Failure modes and mitigation; Security – System limits |
BSI C5:2020 |
OPS-01 – Operational monitoring |
SOC 2 Type II |
CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring |
CSA STAR |
CCM Logging and Monitoring |
CIS Controls v8 |
CIS 13 – Content Filtering |