Papers on GRCDevSecOps, AI governance, and the architecture we built to make continuous assurance real. Read them as arguments, not sales pitches. If the argument holds up against your environment, we would like to talk about it.
Why governance belongs in the pipeline, not the report.
DevOps closed the dev and ops wall. DevSecOps closed the dev and security wall. GRCDevSecOps is the next wall. Governance, risk, and compliance still run weeks behind engineering. They do not have to.
A category argument. Four architectural principles, what the pipeline looks like in practice, and the objections we hear answered honestly. For CISOs and GRC leaders who have noticed that compliance automation is still running weeks behind engineering.
Why AI governance starts in the SDLC, not after deployment.
AI governance is becoming a procurement question before it is a regulatory one. Buyers want to see controls operating, not a slide that says "responsible AI." Most teams are not ready, not because they do not care, but because the instrumentation built for shipping software does not emit the evidence governance asks for.
This paper describes the architecture of an integrated cyber risk fabric and what changes when governance becomes a byproduct of how software gets built. Maps cleanly onto NIST AI RMF, ISO 42001, EU AI Act, and the Cloud Security Alliance AI Control Matrix.
How Xiaotime Labs built the continuous monitoring runtime the industry has been describing for fifteen years.
For fifteen years the cybersecurity industry has known what good continuous monitoring should look like. NIST wrote it down in 2011. HITRUST, ISO 27001, SOC 2, and the new NIST AI Risk Management Framework all describe the same destination from different vantage points: a defender who detects, classifies, decides, and responds fast enough and with enough context that adversaries lose decision dominance. Nobody built it.
What got built instead is a tool ecosystem: SIEMs that detect, GRC platforms that report, SOAR runbooks that block-and-isolate, code scanners that find vulnerabilities, tickets that track them, and humans who spend their weeks ferrying signals between the silos. Each tool owned its slice. None of them owned the integration runtime. ICRG is that runtime. It ingests from whatever security tools you already run, projects every observation through every applicable framework simultaneously, advances findings through a closed remediation pipeline that ships actual code changes through actual review gates, and preserves human authority at exactly one place: production-deploy authorization.
Including governance. The velocity case for GRCDevSecOps, for the CIO and CTO.
Everything as Code is five years old. AWS's Well-Architected DevOps guidance names seven sub-disciplines. None of them is governance. Policy still lives in PDFs, controls still live in spreadsheets, evidence still gets collected by humans against quarterly deadlines. The velocity gain at the engineering layer gets taxed by the latency at the governance layer.
This is the companion paper to the GRCDevSecOps position paper. Where that paper makes the architecture argument for the CISO, this one makes the velocity argument for the CIO and CTO who has to sign for the budget. Four more categories on the same maturity curve: policy as code, controls as code, evidence as code, and audit as code. The fix is not faster reporting. It is moving governance into the code layer.
Why a fleet of AI agents is only as trustworthy as the control point they all share.
A fleet of autonomous AI agents is two new things at once. A new attack surface, because every agent calls models, carries tools, and reaches into real systems. A new audit surface, because every action an agent takes is something a security team will eventually ask you to account for. Most platforms answer neither well, because the agents were assembled one integration at a time.
This paper makes the architecture case for the CISO and the security team. Harness every agent to one mediated control point its reasoning cannot route around, and attribution, policy, and the audit record stop being a layer bolted alongside the work and become properties of every call. The substrate companion to Closing the Loop: where that paper describes the continuous monitoring runtime, this one describes the architecture that makes running a fleet of agents defensible.
How the as-code stack stops being something AI gets checked by, and starts being something AI authors, operates, and governs.
Everything as Code is the long climb where each manual chore becomes a file you can version, review, and test: infrastructure, configuration, the network, the documentation. The explainer genre always ends the same way, naming the apex it will not claim to have reached. Org as Code: someday, maybe, even company policies and workflows will live in Git. This paper is DoctorWhiskers, the platform's AI chief of staff, narrating why the someday is now.
Once the organization itself is code, an AI agent does not just get checked by the gates. It authors the controls, runs the loop, opens the remediation PRs, and then runs through the same gates it wrote with no carve-out. That recursive integrity is what makes Org as Code defensible instead of reckless. It is also what turns governance from a cost center into leverage, and turns the codified workflow into a product you can ship. The medium is the argument: an AI agent explaining how AI agents author, operate, and govern the as-code stack.
If any of these arguments line up with what you are working on, we would like to hear about it. Thirty minutes, no slides. If there is no fit, we will say so plainly.