CSO Playbook
Architectural security conformance, audit evidence, and governing AI-generated security-relevant code.
Setting up your Security Pillar
Before the rest of this guide applies, a Security Pillar must exist with active Lenses. If this is not yet configured, start here.
- Navigate to
/steerings/pillars— check whether a Security Pillar already exists. If not, create one and assign yourself or a security architect as owner. - Navigate to
/steerings/lenses— check how many Lenses are linked to the Security Pillar. This is your LPP (Lenses per Pillar) value for the Security Pillar. - A Security Pillar with fewer than 3 Lenses has shallow coverage. Each Lens must be authored via a Change Intention and approved before it activates.
Starter Lens examples
A Lens has a name (the design rule) and a prompt (the invariant check evaluated on each PR). The prompt is a binary enforcement question — not a policy statement.
“Does any service in this PR call the authentication service directly without routing through the API gateway?”
“Does this PR introduce a new external integration without a data classification declared in the Architecture Ledger?”
“Does any external-facing service introduced or modified in this PR access the database directly?”
Weekly security conformance check
Run this review each week. It should take under 15 minutes if the Security Pillar is configured correctly.
Security Pillar PCR
Navigate to /changecontrols/designaudits, filter by Lenses under the Security Pillar, and compute the pass rate. This is your weekly architectural security conformance number.
BLOCKED PRs under Security Pillar Lenses
In the same view, filter to BLOCKED status. These are the architectural security violations that were caught before merge. Review each: was it resolved by a named approver? Was a justification recorded? Any BLOCKED PR merged without a decision record is a gap.
UDR for Security-domain entities
Ungoverned Drift Rate for entities under the Security Pillar — structural changes to security-critical systems without an approved Change Intention. These are the changes a future audit cannot explain.
ADRIFT — Security domain
Agent-authored PRs that violated Security Pillar Lenses. This is your weekly AI security risk signal. A non-zero ADRIFT for the Security domain means AI coding agents are generating structural changes that contradict your security architectural intent.
Audit preparation — what rkito produces
For SOC 2, ISO 27001, or regulatory audits, the following records are produced automatically by the CDA pipeline — no separate evidence-collection exercise required.
Per-PR Security Lens evaluation record
Which security Lenses evaluated each PR, pass/fail results, and specific findings. Present for every PR that touched code under a Security Pillar Lens.
CHI approval records for security-relevant structural changes
Who approved, when, what was in scope, and what was reviewed. Named approver with timestamp.
BLOCKED PR history
Evidence that security violations were caught and handled, not silently merged. The record shows the violation, the Lens it violated, the decision, and the outcome.
- Navigate to
/changecontrols/designaudits - Filter by Security Pillar Lenses
- Set the date range to the audit period
- Export
AI agents and security architecture
The specific risk ADRIFT measures for the security domain.
AI coding agents generate security-relevant structural changes — new service integrations, new data access patterns, new API endpoints — without any awareness of the organisation’s security architectural intent. The ADR that prohibits direct database calls from external-facing services exists. The agent has no access to it.
ADRIFT broken down by the Security Pillar shows specifically how much of the agent-generated code violated security design rules. This is the number that justifies security-specific agent governance investment.
Navigate to Agent Shepherd to see which agent sessions queried Security Pillar Lens context. The relevant metric is MCPCAR (MCP Context Access Rate) filtered to the Security domain. A low MCPCAR for Security means agents are generating security-relevant code without loading constraints first.
Calibrating Security Lenses over time
Security Pillar Lenses need maintenance as the threat landscape and architecture evolve. This is not a one-time configuration.
Review each Security Lens at /steerings/lenses — is the prompt still describing a real architectural security boundary? Outdated Lenses generate noise and erode trust in the pipeline.
Author a new Lens via /steerings/lenses. Submit via Change Intention for approval before it activates. This creates an approval record for the security control itself — useful in audits.
Track LPP for the Security Pillar over time. A rising LPP means the Security Pillar is accumulating more machine-enforced coverage. A flat LPP means the security architecture is not being translated into enforceable constraints.
Your role in Steering
Security governance in rkito lives in the Steering layer. You own the Security Pillar and the artefacts that define what secure architecture looks like for this organisation.