Evidence, testing & incidents

Evidence hierarchy

Use complementary evidence:

1. Governance design — ownership, purpose, capability manifest, standards and approved limits.
2. Enforcement configuration — identity, policy, allowlists, limits, revocation and containment.
3. Operating records — traces, approvals, denials, anomalies, changes and exceptions.
4. Test results — repeatable evidence that required behaviour occurs.
5. Independent challenge — security review, adversarial testing or internal audit proportionate to the target authority.

A policy alone shows intent. A configuration screenshot alone may be stale. A successful test of one path does not establish complete coverage.

Evidence by element

Element	Useful evidence
Identity	Registration, immutable IDs, credential lifecycle, owner records, purpose and capability manifest
Behavior	Structured trace schema, end-to-end attribution, baselines, alerts, investigations and explanation records
Data Governance	Schemas, injection tests, sensitive-data rules, output validation, provenance and lineage
Segmentation	Enforced resource/action policies, denied events, rate/transaction limits and isolation design
Incident Response	Breaker triggers, kill and revocation drills, rollback/compensation tests and degraded-mode evidence

Safe testing principles

• Obtain authorisation.
• Use a bounded environment and non-destructive payloads.
• Define expected behaviour and pass criteria before execution.
• Protect real credentials and personal data.
• Capture timestamps, agent version, policies and environment.
• Verify monitoring and evidence generation, not only the immediate response.
• Stop if unexpected harm or uncontrolled propagation occurs.

High-value test patterns

• Present a valid identity with an unauthorised action.
• Attempt a permitted action against an unapproved resource.
• Exceed a rate or transaction limit.
• Repeat acceptable actions to test cumulative containment.
• Introduce untrusted instructions through retrieval or a tool response.
• Place sensitive data in input and output paths.
• Break an observability dependency and verify safe degradation.
• Trigger a circuit breaker and prove active work stops.
• Revoke sessions and verify downstream authority disappears.
• Execute rollback or the documented compensating action.

Findings

Raise a finding when:

• A MUST requirement is not satisfied.
• A SHOULD exception lacks defensible reasoning.
• Evidence belongs to another agent, version or environment.
• A boundary is documented but unenforced.
• A test fails or cannot be performed.
• Monitoring does not lead to action.
• Incident history contradicts the current level.
• A promotion gate is asserted without evidence.

Severity should reflect credible impact, exploitability, authority, affected systems, detectability and recovery—not the control label alone.

Incident effect on the assessment

After an incident:

1. Contain and reduce authority.
2. Preserve evidence.
3. Reassess affected requirements.
4. Record root cause and contributing control failures.
5. Verify remediation through testing.
6. Review whether the current level remains justified.
7. Require fresh promotion evidence before restoring greater autonomy.

Do not close the governance finding merely because service was restored.

Evidence review checklist

• Evidence names the selected agent and version.
• The environment matches the conclusion.
• Records cover a representative period and operating conditions.
• Negative paths and exceptions are visible.
• Tests have objective pass criteria.
• Failed tests remain adverse evidence until verified remediation.
• Incident evidence is reflected in maturity and gate decisions.
• Sensitive evidence is accessed and shared proportionately.