Blog
AI on rails. Humans at the switch.
Writing on AI delivery governance. Every post here backs its argument with something you can check: a command, a real transcript, a cited number, or a policy rule that refuses to compile.
- Platform lead / CISO4 min read
TruStacks works on Azure DevOps, in Preview. Keep your repos and your pipelines
TruStacks connects to Azure Repos as a git host and writes Azure Pipelines as your CI. A personal access token is delivered sealed to your runner and never stored by TruStacks. The crew reads your service repos, writes an Azure Pipelines extends template with tasks pinned to full versions and containers pinned by digest, checks it against the signed policy before the pull request opens, and a named human merges. The integration is in Preview: it works end to end in our tests and is ready for teams on Azure DevOps to validate in their own organization.
Read the post - Platform Engineering lead / CTO4 min read
TruStacks is officially in Beta
TruStacks is in Beta and open to the first 50 teams, free for 45 days with no card needed. TruStacks is AI delivery governance: the control layer between the people and AI that write your software and the systems that run it. Its agent crew reads your repository, framework and deployment target, writes the pipeline, and proposes it as a policy-checked pull request a human merges.
Read the post - VP Engineering / Platform lead6 min read
Freedom without rules is chaos. But rules shouldn't slow you down.
Freedom without rules creates chaos, and rules enforced through endless manual work create bottlenecks. The way to enforce delivery standards without slowing engineers down is to make the right way the easiest way: generate the pipelines, manifests and security gates your standards require, evaluate them against policy before review, and leave the merge with a person.
Read the post - Platform lead / VP Engineering10 min read
Drift is a change that skipped the review
To keep staging and production consistent, close the side doors rather than diffing the results. Configuration drift is almost always a change that reached one environment by a path that skipped review: a console edit, a hand-set variable, a runtime patched in staging and never in production. Route every change to what runs through one reviewed pull request path, checked by the same rules for every target, with production defined by a declared tier rather than by a name. That stops the drift changes cause. It does not make staging's data or traffic look like production's.
Read the post - CISO / Security7 min read
Don't take our word for it. Verify our software.
To verify a vendor's container image, run cosign verify against two strings the vendor publishes: the certificate identity of the release workflow allowed to sign, and the OIDC issuer that vouched for it. A green result means that workflow signed that exact digest and nothing has changed since. A signature proves who built an artifact, not that its delivery followed your rules; that takes policy evaluated before review.
Read the post - CTO / Procurement6 min read
Your AI platform shouldn't own your rules.
Before you adopt an AI engineering platform, ask what happens to your engineering standards if you stop using the vendor tomorrow. Keep the rules and the delivery artifacts that implement them outside the platform: policy in an open language, tested with a stock engine, and pipelines, charts and GitOps configuration as reviewable files in your own Git. Buy the capability. Keep the control.
Read the post - Compliance lead / CISO8 min read
Your SOC2 evidence binder should be a side effect, not a project
You generate SOC2 change-management evidence automatically by changing how changes ship, not how evidence is gathered. If every change arrives as a pull request already checked against versioned policy, and a named person merges it, the record an auditor samples is written while the work happens. Assembling the binder becomes exporting a window, rather than reconstructing one from tickets, chat, and screenshots.
Read the post - CTO / VP Engineering8 min read
The architect who knows why the legacy service deploys on Sunday nights is retiring
To keep tribal knowledge after the person who holds it leaves, turn each mechanical constraint they carry into a rule that is enforced rather than merely written down: drafted with them, tested, version-controlled, and checked against every proposed change before it becomes a pull request. Documentation records a rule. Enforcement keeps it true once nobody remembers why it exists.
Read the post - CISO / VP Engineering7 min read
The clock is now hours. Your patch process is weeks
To patch faster without breaking change management, make the controls fast instead of removing them. Most of a patch's elapsed time is waiting: for a review board, for evidence, for a deploy window. A policy gate that runs on every fix in seconds, one named human approval, and an audit record written as a side effect remove the waiting and keep the control.
Read the post - CTO / Platform lead5 min read
The interesting part of a decision is what you turned down
A changelog tells you what a company built. It cannot tell you whether the shape was reasoned about or arrived at by accident, because both produce the same list of features. The useful record is the one that says what was decided against: reselling inference, auto-applying low-risk fixes, flattening the policy layers, exempting ourselves from our own gate. Four decisions, each with the tempting alternative we rejected.
Read the post - Platform lead / CISO6 min read
Your policy engine governs your pipeline. Ours governs the change
Most delivery platforms have had policy-as-code for years: Harness shipped OPA-backed Policy as Code in 2022, before we existed. But those engines were designed to govern the platform's own entities: pipeline configs, feature flags, infrastructure definitions. None of them was built to evaluate the content of a change an AI agent just proposed. That is a different object, and it needs the gate in a different place: between the agent and the pull request.
Read the post - CISO / VP Engineering5 min read
44% of AI code-generation tasks introduce a vulnerability. Your pipeline doesn't know which 44%
In Veracode's 2026 benchmark, 44% of AI code-generation tasks introduced a known security flaw, and AI now authors roughly half of all committed code. The usual answer is more scanning. Scanning tells you after the merge, at a volume nobody triages. And the telemetry shows review time and production incidents both climbing faster than throughput. What scales with agent output is a check that runs on every proposal before a human ever opens it.
Read the post - Platform lead6 min read
Prompts are not policy
The usual way teams control AI coding agents is a prompt: an AGENTS.md, a system preamble, a paragraph of standards. A prompt is a request, evaluated probabilistically, and it cannot be versioned into evidence, tested, signed, or proven to have gotten stricter. A policy bundle can be all four. The distinction is the difference between hoping and enforcing.
Read the post - Platform / Security engineering4 min read
Your AI code compiles. That is not the same as correct
AI-generated code now compiles at a near-universal rate while only 56% of generation tasks produce secure code. The gap between those two numbers is the problem: AI code increasingly looks right, compiles, and reads naturally while still carrying a security flaw. That is the failure mode human review is worst at catching, because nothing about it looks wrong.
Read the post - CISO / Head of Security5 min read
Shadow AI is shadow IT that writes code
Shadow AI is the unsanctioned use of AI tools inside an organization, and it is shadow IT with a shorter fuse: the output is not a spreadsheet in a personal Dropbox, it is code on its way to your cluster. Source code is now the largest category of sensitive data in generative-AI policy violations. The response that works is a governed path faster than the ungoverned one, not a stricter ban.
Read the post - CTO / VP Engineering6 min read
Your AI agent should not have merge rights
AI agents should not be able to merge code, because the merge is where accountability lives rather than where the AI's competence runs out. An agent cannot be accountable to an auditor or an incident review, so the approval step is the one part of software delivery that cannot be delegated. Everything upstream of it can.
Read the post
Prefer a reader? Subscribe via RSS.