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.
/steerings/pillars — check whether a Security Pillar already exists. If not, create one and assign yourself or a security architect as owner./steerings/lenses — check how many Lenses are linked to the Security Pillar. This is your LPP (Lenses per Pillar) value for the Security Pillar.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.
Navigate to /changecontrols/designaudits, filter by Lenses under the Security Pillar, and compute the pass rate. This is your weekly architectural security conformance number.
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.
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.
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.
Which security Lenses evaluated each PR, pass/fail results, and specific findings. Present for every PR that touched code under a Security Pillar Lens.
Who approved, when, what was in scope, and what was reviewed. Named approver with timestamp.
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.
/changecontrols/designaudits“How did you ensure that code changes complied with your security architecture?” — The CDA pipeline answer: automatically, on every PR, with these specific Lens criteria, producing these specific results.
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.
rkito MCP integration loads Security Pillar Lenses into the agent’s context before code generation. The agent knows what is prohibited before it writes. Agents operating with Security Pillar Lens context approach zero ADRIFT for the security domain.
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.
If LPP for the Security Pillar is healthy but false-positive rate (AFPR) is rising, update the Lens prompt via CHI to be more precise. Imprecise Lenses get bypassed by teams — they are worse than having no Lens.
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.
The governance chain: Compliance → Policy → Lens + Prompt → CDA evaluation → audit record. Every link in that chain lives in Steering. A gap at any link means the compliance requirement is declared but unenforced.