SecDevOps in
the Agentic Era

SecDevOps — Security Development Operations — is the practice of integrating security governance directly into the development lifecycle. Not as a post-deployment audit. Not as a quarterly penetration test. As a gate in the CI/CD pipeline, enforced on every change, before the code merges.

The standard SecDevOps toolchain handles the code surface well: SAST (static application security testing), DAST (dynamic analysis), dependency scanning, secrets detection, container scanning. These tools are mature, widely adopted, and genuinely effective at what they do.

What SecDevOps has not yet addressed is the design surface: architectural decisions that create security exposure not through insecure code, but through insecure design. A service boundary crossed that should not have been crossed. A compliance constraint violated because the developer did not know it existed. A data residency policy ignored because no gate enforced it. These violations pass every SAST scan. They are invisible to dependency checkers. They merge.

Traditional SecDevOps assumes human developers who can be trained, who can read the threat model, who understand — at some level — the security architecture they are building against. Developer education is a first-line SecDevOps control. It is imperfect, but it exists.

An AI coding agent has none of this context. It generates syntactically correct, stylistically idiomatic code with no knowledge of the security-relevant architectural constraints in force for the system it is modifying. It does not know that a new component in the payments domain must comply with PCI-DSS isolation requirements. It does not know that the ADR from six months ago prohibited any new direct database connections from the API gateway layer.

The code the agent produces passes the SAST scan. It passes dependency scanning. It passes the linter. It passes code review — because the human reviewer is checking the code, not the design decision the code encodes. The security architecture violation is silent.

The rate at which AI agents are generating production code has outpaced the rate at which security architects can review it. The SecDevOps pipeline has not evolved. The gap is growing with every PR.

The missing layer of SecDevOps for the agentic era is design intent enforcement: verifying that the design decisions encoded in a PR conform to the security constraints in the Architecture Ledger and Steering artifacts — automatically, at every PR, before merge.

This is not SAST. This is not dependency scanning. This is a different class of check entirely. The question is not “does this code have a known vulnerability?” The question is: “The ADR that introduced the payments domain six months ago required that all components touching payment data comply with PCI-DSS isolation. This PR adds a new component in the payments domain. Does it conform to that architectural requirement?”

That question cannot be answered by any code-analysis tool. It requires the design intent to be captured — in Steering artifacts, in the Architecture Ledger — and a gate to enforce conformance at every PR. That gate is the Continuous Design Audit.

In rkito, security constraints are expressed as Steering artifacts — Compliance documents, Policies, and through them, Lenses. A Lens operationalizes a security or compliance principle as a set of binary yes/no questions that can be evaluated against a code diff.

When a PR is opened, the CDA evaluates the diff against all applicable Lenses, including security-relevant ones. The result is binary: the PR either conforms to the security architecture or it does not — and if it does not, the security architect sees the specific finding before the code merges. Not the full PR. The specific finding. The specific principle it violates. The specific ADR or Compliance document that it contravenes.

This is SecDevOps for the agentic era. Not scanning code for vulnerabilities — existing tools do that well. Enforcing design decisions for conformance to the security architecture — at every PR, automatically, regardless of whether the code was written by a human developer or an AI agent that had no context about the security architecture it was modifying.