I have sat through the sixty-slide version. A vision statement, three pillars, a maturity model with the company helpfully placed one notch below "leading," a technology radar, and a roadmap swimlane that runs eight quarters into a future nobody in the room will still be employed to see. Everyone nods. The deck earns a round of "great work," it lands in a shared drive, and a week later not one person who sat through it can repeat a single sentence. The gap between quoted and filed is almost never the quality of the thinking. It is the artifact.

I should be clear about my vantage. I do not author the enterprise IT strategy. I run security and DevOps, and the platform we built on top of them, which is a real slice of the technology function and not the whole of it. But I write the strategy for that slice, I defend it to a board, and I have watched enough of the sixty-slide kind get built and quietly ignored to be confident the failure is structural. The deck is not a neutral container for good thinking. It is a machine for avoiding the one thing a strategy is supposed to do.

Strategy is a set of choices, not a catalog of intentions

Richard Rumelt, in Good Strategy Bad Strategy, gives the cleanest diagnosis I know for why these documents fail. Good strategy has a kernel: an honest diagnosis of the hardest problem you actually face, a guiding policy for dealing with it, and a coherent set of actions that follow from the policy. Bad strategy is the absence of that kernel dressed up to look like its presence: fluff, a refusal to name the real challenge, and the most common failure of all, mistaking goals for strategy. "Modernize the core," "become data-driven," "reach level four maturity" are ambitions with a deadline. They tell you where you would like to arrive and nothing about the road.

The deck is where that failure hides most comfortably, because a deck can list everything without choosing anything. Twelve initiatives, all funded, all important, all on the roadmap. That is a budget with a design template. A real strategy is subtractive. It names the one or two problems that matter this year, commits real resources to them, and by committing, starves everything else. If your strategy document does not leave someone in the room a little unhappy about what did not make it on, you have written a plan. A plan is a list of what you will do. A strategy is an argument about why this and not that.

Write it in prose, because the format is load-bearing

Slides let you hide the logic in the white space between bullets. "Consolidate tooling — reduce vendor risk — improve developer experience" reads like an argument, but it is three fragments in a trench coat, and the causal claims that connect them are exactly the part a bullet lets you skip. Prose will not let you skip them. To write "we are consolidating on one platform, which we expect to reduce vendor risk and improve developer experience, at the cost of the teams that preferred their own tools," you have to hold the claim and its price in the same sentence. That sentence is harder to write because the thinking behind it is harder to do, and the deck was letting you avoid the thinking.

Amazon is the well-worn example: the widely reported practice of banning slide decks in favor of a six-page written narrative that everyone reads in silence at the start of the meeting. Whatever you make of the ritual, the underlying claim holds. A narrative you read as connected paragraphs exposes gaps that a bulleted list conceals. When I write the strategy for my own slice, the useful version is never the deck. It is the memo, a page or two, that a colleague could read cold and come away able to state what we are betting on and what we are giving up to make the bet. The one-pager is not a compression of the deck. It is a more honest artifact, and most of the time the deck should have been the appendix all along.

Name the tradeoff, not just the ambition

Every real strategic choice costs something, and the section that most reliably separates a strategy from a wish list is the one that says out loud what you are giving up. Most strategy documents are all upside. Standardize the platform and gain operability, reliability, lower cost, happier engineers, world peace. But standardization has a price: teams lose the freedom to reach for the locally optimal tool on each job. A document that will not name that price is not asking the reader to trust a decision. It is asking them not to notice that a decision was made.

I will use my own slice as the example, because it is the one I can speak to without inventing anything. We built AgentOS, a governed internal agent platform, on a specific bet: that in regulated fintech the control plane around the model, not the model itself, is where governance actually lives, and that owning that layer is worth building rather than buying. That is a strategy sentence, and it carries a real sacrifice. Building the harness means we carry maintenance a vendor would otherwise carry, and we move slower on some capabilities than a team that bolts a thin wrapper onto a hosted model. I put the tradeoff in the strategy on purpose. If a director or a peer disagrees, I want them arguing with the actual choice, control-plane ownership versus speed-to-feature, not with a paragraph of benefits that pretends the choice was free. A tradeoff you named is a decision you can defend. A tradeoff you hid is a landmine the next reorg steps on.

The anti-roadmap is the part they will actually quote

Michael Porter's line that the essence of strategy is choosing what not to do has been quoted so often it has gone soft, and it is still the most operational sentence in the field. The most valuable page in a strategy document is frequently the list of things you are explicitly not going to do this year: the platform you are not adopting, the rewrite you are not starting, the shiny category you are going to sit out. I have come to think of it as the anti-roadmap. It is the page executives remember, because it took courage to write and it gives them cover to say no.

The mechanism is simple. A CEO cannot personally hold the two hundred decisions the organization makes each quarter, but they can hold three sentences about what the company has decided not to chase. When a vendor corners them at a conference, or a board member floats the initiative that is fashionable this month, the anti-roadmap is what they quote back: we looked at that and made a deliberate call to sit it out this year, and here is why. That is the strategy doing its real job, traveling into rooms you are not in and holding a line you are not there to hold. A roadmap tells people what to work on. An anti-roadmap tells them what to decline, and declining is where most strategies quietly succeed or fail.

Quotable is a distribution decision, not a writing style

The only distribution mechanism that scales is quotation. You will present the strategy a handful of times. After that it propagates, or fails to, by being restated by people who were never in the room, secondhand and thirdhand, in meetings you will never hear about. Every restatement is a lossy copy. If the original is a sixty-slide deck, the copy that survives three hops is noise. If the original is one sharp sentence about the bet and one about the sacrifice, the copy that survives three hops is still recognizably the strategy.

So I write for the restatement, not for the presentation. The test I use is embarrassingly simple: a week after I brief someone, can they tell me the strategy back, in their own words, and get the bet and the tradeoff right? If they can, the document worked, however thin it looks. If they cannot, no amount of production value will save it. The thinking was either not clear or not memorable, and both are my problem to fix, not the reader's. A strategy the CEO can quote is not a dumbed-down strategy. It is a strategy that finished the last mile of its own thinking, and kept going until it was small enough to carry out of the room.

Write it to be repeated

If you are about to author an IT strategy, or rescue one, resist the deck a little longer and do four things instead.

• Name the hard problem, then choose. One or two real challenges, an honest diagnosis, and a bet, not a catalog of everything the function will touch next year.
• Write the one-pager first. If the argument does not survive as prose a colleague can read cold, the deck is hiding a gap, not filling one.
• State the sacrifice in the same breath as the ambition. A tradeoff you named is a decision you can defend; a tradeoff you hid is the next reorg's landmine.
• Publish the anti-roadmap. The list of what you are deliberately not doing is the part that travels, and the part that holds the line when you are not in the room.

The deck was never the deliverable. The sentence the CEO repeats when you are not in the room is the deliverable, and everything else is production value stacked on top of it.

A list of projects is a backlog wearing a Gantt chart's confidence. It tells you what a set of teams intends to build. It does not tell you what the business will be able to do that it cannot do today, which of those new abilities matter most, or what gets turned off to make room. It is silent on all three, because it was assembled by collecting everyone's asks and sorting them by who asked loudest.

Let me place myself. A technology roadmap is a chief-information-officer's document and I am not in that chair yet. I run security and DevOps for a fintech that has to prove its controls to more than 1,500 financial institutions and their examiners, and we built AgentOS, a governed internal agent platform with real users. I own a slice of that plan and report its return to a board, which keeps asking the one question a project list cannot answer: why this, and why now.

A backlog is a list of asks. A strategy is a set of bets.

The project-list roadmap feels inevitable because it is the path of least resistance. Every stakeholder arrives with a request. Sales wants the integration that unlocks the enterprise segment. The support org wants the ticketing overhaul. An executive read something on a flight and wants the AI feature. Each ask is legitimate. The roadmap becomes the union of all of them, prioritized by a rough blend of political weight and recency, and the result reflects the org chart far more faithfully than it reflects the strategy.

Melissa Perri named this failure mode the build trap: an organization that measures itself by the features it ships instead of the outcomes those features produce. Teresa Torres compressed the corrective to four words, outcomes over outputs, and Marty Cagan has spent a decade arguing that a feature roadmap is a commitment to build things whether or not they work. The through-line is that a project is an output. Whether building it changed anything the business cares about is a separate question, and a checkbox going green is the only answer a project list can give.

A strategy answers "why now." It states the outcomes the business is trying to move: win the enterprise segment, cut the cost to onboard an institution, close the books faster, reduce the loss exposure the examiners keep flagging. Then it treats projects as hypotheses about how to move them. Reframed that way, the loudest-stakeholder problem dissolves. You stop arbitrating between a sales ask and a support ask and start asking which outcome each one serves and how far it moves the needle. That is a conversation the evidence can win instead of the org chart.

The unit of a roadmap is a capability, not a project.

Outcomes tell you why. They do not give you anything durable to organize a multi-year roadmap around, because outcomes shift with the market and the quarter. The layer that stays still long enough to plan against is the business capability: the set of things the organization must be able to do, stated independently of whichever system or project currently does it. Onboard a financial institution. Decision a request. Detect and respond to an intrusion. Prove a control to an examiner. Those sentences will be true five years from now. The applications and projects underneath them will have turned over completely.

This is the core idea behind capability-based planning, which lives in enterprise-architecture frameworks like TOGAF and in the business-architecture community's capability maps. Model what the business needs to be able to do, assess how well each capability is served and how much it matters, and point investment at the gaps. A roadmap built on capabilities survives the churn beneath it, because a capability is a stable noun and a project is a disposable verb.

Capabilities also differ in how fast they should change, and conflating those speeds is how roadmaps get their tempo wrong. Gartner's pace-layered model is the cleanest way I have seen to sort them:

• Systems of record. The capabilities the whole business depends on and rarely differentiates on: the ledger, the core, the identity backbone. They should change slowly and deliberately. The roadmap's job here is stability and risk reduction, not novelty.
• Systems of differentiation. The capabilities where you actually compete. How you onboard, how you decision, how you prove trust to a regulated buyer. This is where most of the roadmap's discretionary energy should go, because this is where a capability gap costs you a deal.
• Systems of innovation. The bets, the capabilities you are not sure you need yet. Fast, cheap, disposable, explicitly experimental. Most should fail and be retired without ceremony, which is only possible if you never wired them into a system of record.

Sorting capabilities into those layers does something a flat project list cannot: it tells you how fast each thing is allowed to move. It stops you from applying innovation-tempo urgency to a system of record, or systems-of-record caution to an experiment. Simon Wardley's mapping work pushes the same insight further — a capability's position on its evolution from novel to commodity should decide whether you build it, buy it, or let it fade — but the pace layers are enough to start.

Nothing goes on the roadmap without a sunset date.

This is the discipline that separates a roadmap from a wishlist, and almost nobody enforces it: every addition names a subtraction. Nothing earns a place on the roadmap without stating what it retires and when. The new identity provider names the two legacy directories it decommissions and the quarter they go dark. The consolidated observability platform names the three tools it replaces and the date their contracts are allowed to lapse. If a roadmap item cannot name what it turns off, it is not a strategy decision. It is accretion, and you should be suspicious of it.

I have written before about running a standing sunset review across the existing application estate, a verdict on every app, so renewal becomes a decision instead of a reflex. This is the forward-facing complement. The estate review cleans up what already accumulated; the sunset-on-arrival rule stops the roadmap from being the machine that accumulates it. A roadmap that only ever adds is a plan to grow the run cost and the attack surface every quarter, forever — because in every real environment the new thing ships and the old thing lingers, kept alive by the one team that never migrated, defended by the sunk cost of what it took to build.

The sunset date is also what makes reprioritization honest. When a new ask displaces something, the project-list version drops the loser and moves on, and the capability it was serving quietly degrades with no one accountable. When every item carries a retirement commitment, cutting it forces the real question into the open: what were we going to build or protect, and what happens to that capability now that we are not? That is a call a leadership team should make on purpose. The project list lets it happen by omission.

Horizons, not a Gantt chart.

The dated Gantt chart is the format that guarantees the roadmap will be wrong and then be blamed for it. It commits to a project landing in a specific quarter eighteen months out, at exactly the moment you know the least about it, and it presents that guess with the same visual confidence as the work starting Monday. The first reprioritization shatters it, and because the whole artifact was a promise of dates, breaking one date discredits the entire thing. Now the roadmap is "unreliable," which is code for "we stopped believing it," which is how organizations end up with no roadmap at all — just a rolling argument about the next quarter.

The product-management community converged on a better format years ago, popularized as Now, Next, Later. Instead of committing dates you do not have, you commit confidence you actually possess. The Now horizon is specific and near-certain: funded, staffed, in flight. The Next horizon is directional — the outcomes you intend to pursue after, with the shape but not the schedule. The Later horizon is a set of bets and hypotheses, deliberately vague, honestly labeled as things you might not do at all. Confidence decays with distance, and the format makes that decay visible instead of hiding it behind a bar chart.

This is not a license to be vague where you should be precise. The Now column should be as concrete as any project plan. The honesty is in refusing to pretend Later has the same status. You re-plan on a cadence and promote items from Later to Next to Now as evidence accumulates, and the promotion is the decision point. Mik Kersten's argument for funding persistent value streams instead of temporary projects lands here too: horizons let you fund the outcome continuously and let the specific projects underneath it change without the whole plan collapsing.

Built to survive reprioritization.

Every roadmap gets reprioritized. A new CFO arrives with a different risk appetite. A reorg redraws the ownership lines. A budget cycle takes ten percent off the top. A competitor ships something that moves a whole segment. The only question is whether your roadmap survives the event as a strategy or dissolves back into stakeholder horse-trading. A project list always fails that test.

When the project-list roadmap meets a budget cut, the exercise is a knife fight over which projects get cancelled, and whatever strategy existed evaporates, because it was never written down anywhere except implicitly in the list of survivors. When a capability-and-outcome roadmap meets the same cut, you decide which outcomes you are willing to fund less, which capability gaps you will tolerate longer, and which systems-of-record risks you will carry another year. The specific projects churn underneath, as they always will, but the map of what the business needs to be able to do stays intact. The cut becomes a set of explicit tradeoffs a leadership team can own instead of a queue that just got shorter.

We built AgentOS this way on purpose. It was never a roadmap of features to ship. It was organized around a capability — let internal teams build and run agents that touch real systems safely — and a small set of outcomes beneath it: keep a human in the loop where the stakes demand it, attribute every cost and action to an identity, prove the whole thing to an examiner. The projects under that capability have turned over more than once. The capability, and the outcomes it serves, have not. That is why it survived its own reprioritizations instead of being relaunched from scratch each time the backlog got reshuffled.

This is also the version of a roadmap a board can govern, and I say that as someone who sits on the reporting side of that table. A list of thirty projects lets a board do nothing but nod. A capability map — here is what the business must be able to do, here is how well each capability is served, here is where we are investing and what we are retiring to fund it — lets a board do its job, which is to ask whether the allocation matches the strategy. Give them the project list and you get a status meeting. Give them the capability map and you get a decision.

Build the roadmap that survives the reorg

If you are staring at a roadmap that is really a backlog, four moves start the conversion. Anchor every item to a business outcome, and delete the ones that cannot name theirs. Organize around durable capabilities instead of disposable projects, and sort those capabilities by how fast they are allowed to change. Make every addition name the thing it retires, on a date. And publish it in horizons of decaying confidence, not dated bars you will spend the year defending.

Then run the test I put to my own slice of the plan. Cut the budget ten percent tomorrow. A strategy tells you which outcomes to protect and which capabilities to let slip. A backlog starts a fight over which projects die. Tell me which version you are running, and what it cost you to find out. I read every reply.

Now trace one thing the business actually asked for across that chart. Onboard one more institution. Ship one more decisioning feature. It does not live in a box. It crosses them. It starts as a request to one tower, becomes a ticket to the next, waits in a queue, gets handed to a third, and somewhere in the crossing the context leaks and the clock runs. The chart optimized every tower. Nobody on it owns the thing the customer was waiting for.

That is the quiet defect in most IT operating models. The chart is a map of specialties, not a map of how value reaches a customer. It answers "who reports to whom." The business was asking "how does work get to me." Those are different questions, and the second one pays the bills.

The case I want to make is for redrawing the function around that second question: around business capabilities and the value streams that deliver them, not around the technology towers we happen to staff. And I want to be honest about where I am standing when I say it. I do not own the whole IT org chart. I own one function, security and DevOps, that I built on purpose against the tower grain, and I report its return to a board. That is one data point, not a mandate. But I ran it deliberately, and it taught me the mechanism.

Towers optimize the layer, not the outcome

Towers are not stupid. They exist for real reasons: specialization, vendor management, a control surface an auditor can find, a career ladder a network engineer can climb. Organizing by discipline was rational when the discipline was the scarce thing. The trouble is what the structure does to the work that has to cross it.

Melvin Conway named this in 1968, and it has aged into a law because it keeps being true. A system's structure ends up mirroring the communication structure of the organization that built it. Staff by tower and you get an architecture stitched together at tower seams, with a handoff living at every seam. The handoff is where the latency hides. Lean people have a tool for seeing it — value stream mapping — and the first thing it shows every time is that the wait between steps dwarfs the work inside them. Your request is not slow because any tower is slow. It is slow because it spent most of its life in a queue at a boundary, waiting for the next specialty to pick it up.

Each tower is measured on its own SLA, and it can hit that SLA all day while the end-to-end capability crawls, because the slow part is the crossing and the crossing is nobody's number. A tower is a fine unit for attributing a cost. It is a terrible unit for organizing a team, because the value the customer bought never lived inside one.

I already ran this experiment at n=2

I have written before about putting security and DevOps under one roof and refusing to apologize for it. The org-chart version of that argument is simpler than the culture version. When security and delivery sit in separate towers, the space between the people who ship and the people who protect is a handoff, and a handoff is a queue. Collapse the two into one function and the queue does not get shorter. It disappears. What used to be a ticket crossing a boundary becomes a tradeoff managed inside one team. The result was not looser control; it was control designed into the pipeline instead of inspected at a gate the work had to stop and pass through.

That is the whole move, run at the smallest scale where it is interesting. Take two towers, remove the boundary, and the cost that lived at the boundary goes with it. This essay is that move reasoned up a level: what happens when the collapse becomes the design principle rather than the exception. I am not going to pretend a two-tower merge proves an enterprise reorg. Two is not forty, and the second-order effects at forty are real. But the mechanism does not care about the count. Every boundary you draw is a queue you are choosing to own, and the question a CIO is actually answering when they draw the chart is which boundaries are worth the queue.

Organize around capabilities, not technologies

The right spine is the one that holds still. The most stable structure a business has is its list of capabilities: the things it does, stated as verbs. Onboard an institution. Decision a request. Serve an account. Close the books. Business architects call this a capability model, and its virtue is durability. Processes change constantly and org units churn with every reorg, but the set of things a company fundamentally does barely moves in a decade.

The team shape that follows is what Team Topologies, from Matthew Skelton and Manuel Pais, calls a stream-aligned team: a team that owns a slice of value end to end, from a change to production, for a single capability. The value chain becomes the org chart. And because Conway's law runs in both directions, you can use it on purpose. That is the inverse Conway maneuver, deliberately shaping the teams to grow the architecture you want instead of letting an accidental org shape you an accidental system.

The tell that you have it right is the set of questions the structure can suddenly answer:

• What is the end-to-end lead time for this capability? A stream-aligned team can tell you. A collection of towers can only report their individual pieces and shrug at the seams.
• Who owns the outcome when it breaks? A name, not a routing table that hands the incident from tower to tower until it lands on whoever is least able to refuse it.
• What does it cost to serve one more unit of this? The capability is the unit the rest of the business already prices its work in, and now IT can answer in the same currency.

The platform is the shared spine, not another tower

There is an obvious way to get this wrong, and it is the failure mode that scares every infrastructure leader out of trying. Reorganize into value streams naively and each stream rebuilds its own plumbing: its own pipelines, its own identity glue, its own logging. You trade a handoff problem for a duplication problem, and forty private stacks is not progress.

The answer is a thin platform beneath the streams — identity, logging, pipelines, the paved road — consumed as self-service rather than requested as a ticket. That last clause is the entire difference between a platform and a tower. A tower hands you a ticket and a wait. A platform hands you a capability and gets out of the way. If your platform team behaves like a tower, with gates and queues and mandates, you have not built a platform. You have renamed the silo.

This is the shape we built AgentOS into. It is a governed internal agent platform, which means the control plane — identity, the action boundary, per-agent logging — sits beneath the teams. A stream that wants to ship a safe agent pulls the guardrails off the platform instead of standing up its own. The governance travels with the platform and the capability travels with the stream. The streams stay fast because they are not each reinventing the plumbing, and the plumbing stays consistent because it lives in one place that everyone consumes and nobody has to petition.

What you keep, and what the examiner still wants

None of this dissolves deep expertise; it changes the shape expertise takes. Team Topologies keeps two other shapes alongside the stream-aligned teams. Enabling teams, which coach the streams and then leave. Complicated-subsystem teams, which own the genuinely hard specialty no single stream should have to carry. The database expert and the network engineer do not vanish in this model. They stop being a tower everyone has to visit and become expertise the streams can pull in when they need it.

Some things stay centralized on purpose, because they are genuinely cross-cutting and, in my world, non-negotiable. The identity model, encryption, the control plane, the examiner-facing evidence: those are the high curbs, and streams do not defect from them. Serving more than 1,500 financial institutions means an examiner will still ask, in plain language, who owns a given control. "The value stream" is not an acceptable answer if it turns out to mean no one. So the move is not to abolish ownership of controls. It is to make the control travel embedded with the stream — a named owner inside the flow, not a checkpoint at its edge.

And I will not oversell it, because Conway's law cuts both ways. A value-stream reorg done badly relabels the towers, adds a coordination tax, and calls the disruption transformation. Draw the streams around the current org chart instead of around the actual path value takes to a customer and you get all the churn and none of the flow. The map you draw first is the whole ballgame. Draw it wrong and the new boxes are the old boxes with better branding.

Draw the value chain first

If you own the chart, or you are reasoning toward the seat that does, a few moves carry most of the weight. Draw the value chain before you draw the boxes: map how a real request reaches a real customer, count the handoffs, and put a team on the flow instead of on the layer. Collapse the boundary where the handoff hurts most, and treat security and delivery under one roof as the template rather than the exception. Back the streams with a thin platform so the shared spine is self-service and never a ticket. Keep the high curbs centralized and the specialties on tap, and make every control travel with a named owner inside the stream.

I have run this at n=2 and I am reasoning openly toward the seat that owns the whole chart. If you have run a value-stream reorg at real scale, or watched one quietly relabel the towers and ship a slide about it, tell me which one you got: where the model held, where it broke, and whether the examiner in your world ever accepted "the stream owns it" as an answer.

On February 19, 2026, the US Treasury published its Financial Services AI Risk Management Framework: 230 control objectives across seven domains, purpose-built for the industry. It is a genuinely good document. Within a week I watched teams across fintech start mapping their models to it, the way we all mapped to the NIST AI RMF the year before, and treat that mapping as the answer to the question every board is now asking: "how do we govern our AI?" In consumer credit, that is the wrong question. It is the second question wearing the first one's clothes.

When your AI touches a credit or financial-wellness decision, the binding constraint is not the newest framework. It is a body of law that has been on the books, litigated, and enforced for half a century: the Equal Credit Opportunity Act and its Regulation B, the Fair Credit Reporting Act, the adverse-action requirements those impose, the CFPB's stated scrutiny of opaque models, and, for the banks you serve, the model-risk discipline of SR 11-7. None of it says "artificial intelligence." All of it governs your model anyway.

The AI-governance frameworks are voluntary, mostly aspirational, and almost entirely unlitigated. Fair-lending law is none of those things. It carries a private right of action, statutory and punitive damages, a fifty-year enforcement record, and a Justice Department that refers pattern-or-practice cases for prosecution. I run information security and platform teams in a regulated fintech that serves more than 1,500 financial institutions, and I will tell you plainly: the framework you will actually be judged against for an AI credit decision is the one that predates the phrase.

The binding constraint is older than the framework

A framework tells you to manage risk. Fair-lending law tells you specifically what you must be able to do, and lets a consumer sue you when you cannot. That specificity is the whole difference, and it is why I keep pulling these conversations back down from the framework to the statute.

The new instruments are real and worth reading. The Treasury RMF gives financial services a sector-specific control set. The EU AI Act's general-purpose-AI obligations switch on August 2, 2026, with fines up to three percent of global turnover. California's CCPA automated-decision rules land in January 2027 and reach any covered business making significant decisions about consumers. These matter. But notice what they are: process obligations and penalty ceilings, most of them prospective, most of them untested in a courtroom. For a US consumer lender, the nearer and sharper edge has already been drawn a thousand times. ECOA does not ask whether you documented your model. It asks whether a real person was denied credit for a reason you can defend, on a basis the law permits.

So use the frameworks as scaffolding. Map to the Treasury RMF; it is good hygiene. But the frameworks inherit their teeth from the underlying law, not the other way around. When an examiner or a plaintiff's lawyer comes for your credit model, they will not ask which AI framework you adopted. They will ask why this applicant was denied, and whether the model treats a protected class worse than it treats everyone else.

Adverse action is a specific-reason requirement, not an explainability nice-to-have

A single requirement quietly decides whether your model is deployable at all. When you deny credit, or offer worse terms, ECOA's Regulation B and the FCRA require you to tell the applicant the specific principal reasons why. Not a category. Not "you did not meet our credit criteria." Not "the model scored you below our threshold." A specific, accurate reason that reflects what actually drove the decision.

The CFPB put this beyond argument in 2022: a creditor cannot hide behind the complexity of an algorithm to escape the obligation to give specific and accurate reasons. "The model is a black box" is not a defense. It is an admission. If your system can produce a score but not a reason a human can stand behind, you have not built an advanced credit model. You have built a compliance liability that happens to return a number.

This is where explainability stops being a research aspiration and becomes a legal precondition, and it is more demanding than the demos suggest, because the reason has to be true. A post-hoc explainer that generates a plausible-sounding factor the model did not actually rely on is worse than no explanation: it is an inaccurate adverse-action reason, which is its own violation. What the law wants is narrow and hard. Reasons that are faithful to what the model did, legible to the person receiving them, and defensible to the examiner reading them later.

A deployable adverse-action capability, in practice, has to produce all of this:

• Specific principal reasons tied to the factors that actually moved the decision, not a generic reason code pulled from a menu.
• Reasons faithful to the model — an accurate account of what the model relied on, not a persuasive story bolted on afterward that the model would not recognize.
• Reasons captured at decision time, not reconstructed months later when a complaint arrives and the model has already been retrained twice.
• Reasons a human can defend to a regulator, in plain language, without a data scientist in the room translating.

The instinct here is one I have built before, in a different context. When my team built AgentOS, our governed agent platform, the non-negotiable was an audit trail and a clean boundary between the moment a system decides and the moment it acts: capture why, at the point of decision, in a form you can produce on demand. Credit decisioning demands exactly that instinct, except the law, not an architecture review, is the thing enforcing it.

Disparate impact does not care what your model intended

Fair-lending law recognizes two ways to discriminate. Disparate treatment is intentional: you treated someone worse because of a protected characteristic. That one is easy to understand and, for a model, easy to avoid on purpose. You do not feed it race. The dangerous one is disparate impact: a facially neutral policy or model that produces a disproportionately adverse outcome for a protected class, whether or not anyone intended it.

A model has no intent. That is precisely the trap. Machine-learning models are proxy machines. Give one enough features and it will reconstruct the protected characteristic you carefully left out, through zip code, through device, through the timing and pattern of transactions, through a hundred correlates you never sat down and chose. The model does not know it is redlining. It found that the variable predicts, and why it predicts is not a distinction the loss function can see.

Under disparate-impact analysis, a discriminatory outcome is not excused by a clean conscience. It is defensible only if the practice serves a legitimate business necessity and there is no less discriminatory alternative that meets the same need. That last clause is the one regulators are pressing hardest on now. The obligation is not merely to test your model for disparity. It is to go looking for a fairer model that performs comparably, a less-discriminatory-alternative search, and to keep the record of having looked. If a model with similar business results and materially less disparate impact exists and you did not adopt it, the disparity is not an accident of the data. It is a choice you made.

So disparate-impact testing and the less-discriminatory-alternative search are not data-science flourishes you get to prioritize after launch. They are the governance obligation, on a schedule, with the evidence retained. The examiner's question is not whether your model performed well. It is whether you checked how it performs for a protected class, and what you did when it performed worse.

SR 11-7 already told you to validate the model

If you sell into banks, as my team does, their examiners have been holding models to one document since 2011, long before anyone said "generative": SR 11-7, the interagency guidance on model risk management. Read it today and it is uncanny how completely it anticipated the AI-governance conversation we are all having as if it were new.

SR 11-7 requires a model inventory: every model, owned, cataloged, and risk-rated. It requires development documentation, so the model is not a folk artifact living in one engineer's head. It requires independent validation by someone who did not build the model, on a cadence. It requires ongoing monitoring for drift, because a model that was sound at launch decays as the world moves. And it requires "effective challenge," a genuinely empowered second set of eyes with the standing to say no. That is not a description of a novel AI-governance program. It is the AI-governance program, written fifteen years ago, for a narrower class of models, by regulators who understood the failure mode perfectly.

The teams treating AI governance as greenfield are re-deriving SR 11-7 badly and slowly. The teams that already live under it have most of the scaffolding and mainly need to extend it to models that are larger, more opaque, and retrained more often. Model inventory becomes a registry that includes your AI systems. Independent validation becomes the effective-challenge function that also probes for disparate impact and adverse-action faithfulness. Ongoing monitoring becomes drift detection with a provenance trail. These are the same governance primitives I build on the security side — a registry of what exists, scoped authority, an audit trail, memory with provenance — pointed at the decisioning model instead of the agent. The discipline is old. AI made it mandatory at a scale and a speed the 2011 authors did not have to imagine.

What to actually do Monday

Stop treating "which AI framework" as the governing question for a credit model, and start with the law that already binds it. Four moves.

Inventory every model that touches a credit, pricing, or financial-wellness decision, and treat SR 11-7 as the floor rather than a voluntary framework as the ceiling. Prove the adverse-action reason before you ship: if the model cannot produce a specific, faithful, human-legible reason at the moment it decides, it is not deployable, no matter how well it scores. Run disparate-impact testing and a less-discriminatory-alternative search on a schedule, and keep the record of having run them. And map your AI framework of choice back onto the fair-lending law it inherits its enforceability from, not the reverse. The Treasury RMF is the scaffolding. ECOA and FCRA are the load-bearing wall.

Explainability in consumer credit was never a nicety you would get to once the model was accurate enough. It is a fifty-year-old legal obligation that AI made harder to meet and impossible to avoid. Govern to the law and the frameworks mostly take care of themselves. Govern to the framework and the law will find you anyway, usually in the form of a denied applicant you cannot explain.

If you build or validate credit models under ECOA and SR 11-7, I want to hear where adverse-action faithfulness actually bites for you: where the model's real reasons and the reasons you can defensibly put on a notice come apart. That gap is where this gets hard, and it is the part the frameworks do not help with.

A researcher pointed Grok Build v0.2.93 at a repository with one instruction: reply OK, and open no files. At the model layer the agent obeyed, and the traffic suggested it touched nothing. Meanwhile the product wrapped around it uploaded a Git bundle of the full tracked repository and its entire commit history, including a canary file the model never opened. That is the reported account. Even if not every detail survives scrutiny, the mechanism is the alarming part.

I run security and platform teams in a regulated fintech, and I sit in a lot of AI vendor reviews. Almost every one opens with the same reassurance, delivered like a closing argument: we don't train on your data. It is usually true. It is also an answer to a question that, on its own, does not protect you, and in the Grok Build account it would have been perfectly true while the entire codebase, canary and all, walked out the door.

Here is the reframe I want to make stick. Data governance has three legs: what a system trains on, how the data travels, and where the data rests, including who can read it there. "We don't train on your data" answers the first leg only, and it is the leg least likely to hurt you first, which is exactly why vendors volunteer it. When someone leads with the answer they can most cleanly clear, that is a tell, not a comfort.

The pledge is true. It just answers one leg of three.

Give the assurance its due; the strong version is genuinely strong. Microsoft's Azure OpenAI commitments state that your prompts, your training files, your outputs, and any model you fine-tune are not used to improve the foundation model or shared with other customers without permission, and that a fine-tuned model is exclusive to you, encrypted at rest, and deletable on demand. That is precise, testable, and contractual: a clean answer to the training question.

It is also doing an enormous amount of load-bearing work, because it is the sentence that makes leaders comfortable pushing regulated data in. And they are pushing. Fine-tuning small models on sensitive material inside a "controlled" cloud boundary is the workload of the moment, and the cited results are real. Microsoft's own customer stories describe Bayer fine-tuning a Phi model on proprietary crop-protection label data so expert questions that took days now resolve in under thirty seconds, and Discovery Bank fine-tuning five variants across Azure OpenAI's 4o-mini and 4.1-mini to cut average response time from five or six seconds to under two. These are exactly the workloads where the most sensitive data goes in, and where "we don't train on it" is the phrase quieting the room.

The model obeyed. The product still shipped the repo.

The model turn and the data path are two different systems, and you can win one while losing the other. An agent can honor an instruction perfectly at the model layer, open no files, touch nothing, while the product around it moves your bytes for reasons of its own: telemetry, context bundling, a background upload to "improve your experience." The model was obedient. The plumbing was never asked. A vendor can truthfully swear it never trained on that repository while its product copies the repository into a bundle or a log.

If that shape feels familiar, it should. This is the exfiltration class one layer up from injection. When Varonis disclosed SearchLeak — CVE-2026-42824, a one-click leak in Microsoft 365 Copilot — on June 15, 2026, nothing broke. The data walked out through trusted, allowlisted infrastructure turned into a courier, because the egress was already permitted. The Grok Build story is the same silhouette with a different courier: the product's own bundling-and-upload path. Your perimeter can hold perfectly and still leak, because the thing carrying the data out is a service you approved.

And then there is the canary. A canary file is a plant that exists to never move; if it turns up somewhere it should not, you know a transmission path is live. In the account, it moved. That is precisely the primitive we use to test whether a boundary leaks, and almost nobody has thought to point one at their AI vendor's product rather than at their own network. The model is not the thing you most need to instrument. The product is.

Interrogate the transmission and storage paths, not the training claim

So retire "do you train on our data" as a standalone checkbox and put the weight on the two legs it skips. A control-plane vendor review should force three answers.

• Where does the payload travel? Bundle, log, telemetry, context cache, a secondary service, a sub-processor. Enumerate every hop your bytes take before the model sees them and after it responds. The Grok Build bundle lived on one of those hops.
• Where does it rest, and for how long? Retention is where a transient prompt becomes a durable record with residency, deletion, and DLP obligations attached. "We don't keep it" is a claim you can hold a retention window and a deletion API against, or it is marketing.
• Who can read it there? Not hypothetical. Under standard Azure abuse monitoring, a sample of flagged prompts and completions can be stored and selected for restricted human review by authorized Microsoft employees, a storage-plus-human-read path that coexists perfectly happily with "we don't train on your data."

That last one is also where the control lever hides. Eligible managed customers can apply for modified abuse monitoring, which turns the human-read path off. It is a documented, requestable knob that a real control-plane review exists to find and turn. The no-train pledge is a contract term; the abuse-monitoring configuration is a data-flow decision. Only one of them is a diagram of where your data actually goes.

The enforcement mechanism underneath all of this is classification, not trust. Map a Red/Amber/Green router onto your existing fintech data classification: material non-public information, credentials, and privileged legal advice are Red, and Red never crosses a boundary whose transmission and storage paths you cannot audit. Green, meaning public or synthetic material, can go almost anywhere. Self-hosting moves this boundary without removing the review. LM Studio will serve requests from other devices on your local network with authentication off by default the moment a second device connects, which is a non-human-identity hole about who can read what, not a training question. Run the model yourself and you still owe the same three answers.

The correction record is the asset, not the weights

Now the part that reframes the vendor relationship. The lock-in was never the weights. Weights are rented reasoning; you can point at a different set this afternoon. The thing that is genuinely hard to move is the correction record: the accumulated ledger of which exceptions your legal team has accepted, which numbers finance has ruled material, which contract clauses carry risk, plus the permissions, prompts, and evaluations you built while teaching the system your world. Nobody hands that to you. You rebuild it from scratch, over months, every time.

Here is what a CIO should see. That record is two things at once, a regulated data asset and an audit artifact, your decision-provenance trail wearing a different hat. When an examiner asks how an automated system reached a call, it is a large part of the answer. It is a different object from a pipeline that generates its own audit trail as a byproduct of running, which I have written about before. This is a record whose whole value is that it is yours to export, not the vendor's to hold.

Which makes the requirement blunt: the correction record must be exportable and vendor-independent. If it lives only inside a vendor's product, you have concentration risk on your single most valuable AI asset, and you have handed a regulator's question, prove you control this decision system, to a company whose answer is a support ticket. Under the US Treasury's Financial Services AI Risk Management Framework — 230 control objectives across seven domains, published February 19, 2026 — the accepted-exception, material-number, risky-clause record is precisely what you will be asked to produce and to prove is yours to control. A record you cannot extract is a control you do not have.

The model-independence test: swap one workflow, inventory the rebuild

All of this stays theoretical until you make it concrete. Here is the test I would run this quarter. Pick one recurring, sensitive workflow. Demand a live model swap on it — not a slide, an actual run of that workflow on a second model behind your own gateway. Then inventory everything the team has to rebuild to make the swap work: the memory, the review rules, the integrations, the tuned behavior, and the correction record itself.

That inventory is the number. The length and cost of the rebuild list is your portability and concentration-risk exposure expressed as work rather than vibes, a figure a CIO reports to the board like any other single-vendor dependency. I have argued that model selection is capacity planning, routing work across models by risk tier. This is the other half of that discipline: not selection but extraction. Own the harness, rent the model, and prove the rent clause works by exercising it before you are forced to.

Because you will be forced to eventually. The test doubles as a continuity rehearsal. When a model is pulled on a regulator's timeline, as two US-lab flagships were in June, suspended three days after launch under an export-control directive, or when a vendor simply changes its terms, the rebuild inventory you already produced is your recovery runbook. The portability metric and the disaster-recovery plan turn out to be the same document.

One discipline makes the whole thing auditable: pin what you can hold. Log the stable model id, claude-opus-4-8, not a floating alias like chat-latest that reassigns under you without a changelog. Pin the version and schedule the re-validation. Then "swap the model" is a config change instead of an archaeology project, and every entry in your correction record stays attributable to a specific version an examiner can name.

Rewrite the questionnaire, then price the rebuild

Demote the training checkbox and add the questions that carry the risk: where does the payload travel, where does it rest and for how long, who can read it, which sub-processors touch it, and can we get modified abuse monitoring in writing. Then require a canary test of the transmission path before any Red data touches a product. Point the plant at the vendor, not just at your own network.

Classify and route: Red stays off any hosted path whose transmission and storage you cannot audit. Own the record by exporting it on a schedule and holding it as regulated audit evidence under your own retention and provenance, mapped once to the Treasury and NIST controls. Measure the lock-in by running one model-independence test this quarter and reporting the rebuild inventory to the board as concentration risk, with a named owner and a date. And close the auth-off-by-default hole on any self-hosted inference.

The pledge is true and nearly beside the point. Ask where the data travels, where it rests, and who can read it. Keep the correction record in your own hands. And price the rebuild yourself, before a vendor's roadmap or a regulator's directive prices it for you.

In a widely reported 2024 case, a finance employee at the engineering firm Arup joined a video call with people who looked and sounded exactly like the company's CFO and several colleagues. Every face on the call was synthetic. Convinced by what he saw and heard, he authorized a series of transfers later reported at around 25 million dollars. Nobody hacked a system. The controls did what they were told. A human recognized his coworkers and acted on the recognition, and the recognition was manufactured.

Treat that as a pattern, not a headline. FinCEN warned in a widely reported 2024 alert about deepfake media used to open accounts and move money, and the FBI has repeatedly flagged voice cloning and synthetic video in business fraud. As reported, the ingredients keep repeating: a cloned voice on a phone call, a synthetic face on a video, a caller-ID that matches, an email thread that reads exactly right. None of it is exotic anymore. It is a paid feature.

I run information security and platform teams in a regulated fintech that serves more than 1,500 financial institutions, and nearly every conversation about this lands on the question the vendors are racing to answer: can we detect the deepfake? Wrong question. It stakes your defense on winning an arms race against a technology whose entire job is to get better at not being detected. The question that protects you is narrower and unglamorous: where in our processes does recognizing someone stand in for proving who they are, and can we remove it?

Detection is an arms race, not a control

I have written before that AI's real effect on attackers is that it raises the floor — it collapses the cost of a fluent, personalized lure and hands the least-skilled attacker a capability they did not have. Synthetic media is that shift applied to identity signals. The lure, the voice, and the face used to be three separate kinds of work with their own costs and skills. AI collapsed all three and dropped them to the price of a subscription. What rose is not one attack. It is the credibility of every channel a human uses to decide they are talking to who they think they are.

The instinct is to meet a detection problem with a detection tool, and a whole market is forming to sell you one. Be careful. Deepfake detection is probabilistic and adversarial: every detector is a target, and the generator is trained to beat exactly that scrutiny. Liveness checks — blink, turn your head, read these digits — are already being defeated by injection attacks that feed a synthetic video stream straight into the camera path, bypassing the lens the check assumes exists. A detector that is 95 percent accurate sounds excellent until you remember the attacker retries for free and only needs to win once. You do not build a money-movement control on a coin flip the adversary gets to reweight.

Detection has a place: as telemetry, as a signal that raises friction, as one input among several. It does not have a place as the thing standing between a request and a wire. Anything you would stake a transfer on has to hold when the fake is perfect, because eventually it will be.

Recognition is not authentication

Here is the reframe I want to make stick, because it is the whole piece. A familiar voice, a recognizable face, a caller-ID you know, an email thread in the right tone — these are all recognition: a probabilistic human judgment that something sounds like, looks like, reads like the person you expect. Authentication is different. It is proving identity with a factor bound to the real person: a key, a passkey on an enrolled device, a callback to a number that person controls, a secret only they hold. We spent decades learning not to trust recognition for machines. We never finished the job for people.

I have made the machine version of this argument before. Your AI agents can authenticate but they cannot prove they are authorized, and the credential quietly becomes the entire identity. The human version is the mirror image. A person on a call can be recognized but not authenticated, and for most of banking history we let recognition quietly become the entire identity, because forging a voice or a face convincingly was hard enough to treat as proof. AI removed that friction. The moment recognition is cheap to forge, every process that accepted "I recognized them" as authentication is a process with no authentication in it at all.

So the audit is simple to describe and uncomfortable to run. Walk every path where money moves, access is granted, credentials are reset, or a payee is changed, and mark each point where the deciding factor is that someone recognized a voice, a face, a name, or a number. Every one of those marks is a control that AI just voided. You are not hunting for the deepfake. You are hunting for the places you were counting on nobody being able to make one.

Move the trust to the channel, not the content

Once you stop trusting the content, the question becomes what you can trust, and the answer is a channel you control the endpoint of. The content of a call is forgeable. A call you place to a number of record is not, because the attacker does not answer at the real CFO's phone. This is the oldest idea in fraud prevention wearing new urgency: out-of-band verification, initiated by you, to an endpoint enrolled before the request existed.

These are the controls I would put between recognition and action, and none of them require a new vendor:

• Callback on a number of record, never a number you were given. The verification value of a callback is entirely in who controls the endpoint. Call the CFO on the number in your directory, not the one in the email or on the caller-ID. If the request is legitimate, you lose thirty seconds. If it is not, the person who answers has no idea what you are talking about, and that is the whole point.
• A pre-shared challenge, and a duress word. A code phrase agreed in advance, out of band, that a synthetic caller cannot know because it was never spoken over a forgeable channel. Pair it with a separate word that means "I am being coerced," because deepfakes are not the only way a real voice ends up making a fraudulent request.
• Dual authorization on money movement above a threshold. Two people, two independent approvals, for any transfer past a line you set. This is the human blast-radius control. One fooled employee is no longer sufficient to move the money, and an attacker now has to compromise two people through two channels instead of convincing one on a video call.
• Payee and bank-detail changes verified out of band, every time. The highest-yield fraud is not a dramatic transfer. It is a quiet edit to where a legitimate, recurring payment lands. Any change to a payee's account details triggers an independent callback to a known contact before it takes effect, with no exceptions for urgency, because urgency is the lever.
• Step-up authentication bound to an enrolled device, not to a voice. When you need a higher-assurance factor, reach for a passkey or a push to a device the person enrolled, which proves possession of a thing the real person holds. A voiceprint proves only that something produced the right sound, and something now can.

Notice the common shape. Every one of these moves the trusted event off the content of the interaction, which the attacker authored, and onto a channel whose endpoint you established in advance. That is the same boundary I build for automated systems: the point where a request becomes an action is the point you instrument and gate, not the point where you decide the request sounded sincere. Sincerity is now generated. The channel is what is left.

Your call center is the perimeter now

For a financial institution, the softest place this lands is not the wire room. It is the help desk and the account-recovery flow, staffed by people whose entire job is to be helpful to someone who says they are locked out. That agent is measured on handle time and satisfaction, and they are now being called by a voice that sounds exactly like an account holder, in distress, with a plausible story and half the right answers. Social engineering against the help desk is an old technique. AI just gave it a perfect voice and infinite patience.

So the control cannot live in the agent's judgment, because judgment is exactly what the deepfake targets. It has to live in the script — a procedure that never accepts recognition as a factor. Roughly the sequence I would enforce:

1. Never authenticate on voice recognition, or on knowledge an attacker can research or phish: a name, a date of birth, the last four digits, a recent transaction. Treat all of it as public.
2. Drive high-risk actions (password reset, MFA re-enrollment, payee change, contact-info change) to a step-up bound to an enrolled device, or a callback to a number of record, not to the call in progress.
3. Give the agent an explicit, blameless path to slow down: a hold, a callback, a supervisor, with metrics that reward the friction instead of punishing the handle time.
4. Log the verification method used, not just the outcome, so the pattern of how identity was actually proven is reviewable after the fact.

The same logic runs through onboarding. Synthetic-identity fraud and deepfake-defeated liveness are the account-opening version of the same problem: a generated face passing a check that assumed a real one. The answer is not a better face detector. It is binding the identity proof to signals harder to synthesize — a verified device, a bank-account link, a channel you control — and refusing to let a single passed liveness check be the whole gate.

A procedure gap is an examiner's question

When you serve more than 1,500 financial institutions, this stops being an internal fraud problem and becomes a design obligation. Every one of those institutions runs a call center and a payments desk, and every consumer they serve is reachable by a cloned voice. The verification procedures are not back-office hygiene. They are the control an examiner asks to see exercised. FFIEC authentication guidance and the GLBA Safeguards Rule already expect layered, risk-based identity assurance, and dual control on payments is table stakes in any serious fraud program. The US Treasury's Financial Services AI Risk Management Framework — 230 control objectives across seven domains, published in February 2026 — pushes the same way: demonstrate the control, do not just assert the policy. "We train our people to spot fakes" is a policy. "No single recognition event can move money, and here is the callback log that proves it" is a control.

What to change before the next call

You cannot buy your way out of this with a detector, and you cannot train your way out by asking people to be more suspicious of a perfect fake. You engineer the recognition out of the decisions that matter. Map every path where money moves or access is granted and mark where recognition substitutes for authentication. Move the trusted event to a channel you control: callback on a number of record, a pre-shared challenge, dual authorization above a threshold. Rewrite the help-desk and recovery scripts so no agent can authenticate on a voice. And treat any detector you buy as telemetry, never as the gate between a request and a wire.

The deepfake is not the breach. The procedure that trusts the face is. Fix the procedure and the perfect fake becomes a strange phone call that goes nowhere.

If you have rewritten a verification procedure to assume the voice is fake, I want to hear where it created friction people actually routed around. That is the part the guidance never covers.

In a connected-agent walkthrough making the rounds this month, someone asked an agent to close out a task in Linear. It marked the task done the instant it was asked: ticket NAT-2391, no confirmation screen, no "are you sure," the write just happened. As reported, that was the whole interaction. A sentence in, a state change out.

Everyone watching that clip saw a productivity feature. I run information security and DevOps for a fintech that serves more than 1,500 financial institutions, and my team built our own governed agent platform, AgentOS, largely to get this exact boundary right. I saw a missing control. The write was correct; that is not the point. Nothing sat between the decision to act and the action.

The loud question about connected agents right now is "what can it do?" Which tools, which integrations, how much reach. That is the wrong question. The reach is bounded, and bounded in ways most people never count. The durable question is quieter: when the agent changed something that matters, who approved it? In a connected-agent world the answer is usually your prompt. Nobody governed that one.

Two limits bound the connection. Count them both.

Start with what an MCP connector actually is, using the framing the tool builders themselves use: it is a menu relationship. The product publishes a menu of allowed actions, and the agent can only order from it. It cannot invent a verb the vendor never exposed. That is a real and reassuring first limit.

Here is the second limit almost everyone forgets. The agent's reach is also bounded by the permissions of the account or workspace you connected it to, because it inherits that principal's scope. Connect it to an admin's workspace and it can touch everything the admin can. Two limits, and they multiply rather than add.

Translate that into the lens a regulated shop already lives in and it is not new at all. This is the same two-tier bound I enforce for every non-human identity: the vendor's published action surface, and the least-privilege scope of the service account the agent borrows. Neither tier is the control by itself. The intersection is. Non-human identities already outnumber humans by roughly 45 to 1, as high as 144 to 1 in some estimates (Cloud Security Alliance, May 2026), and each connector is one more of them.

So the posture is not a preference. Read-only by default, the narrowest workspace that does the job, and explicit scoped write requests are governance controls, not developer conveniences. The default an engineer picks in an afternoon is the blast-radius decision an examiner asks about a year later.

The approval screen you didn't see is the control you didn't build

The mechanic the Linear clip exposes, stated plainly: some tools, Codex among them, may not surface a separate approval screen for a write action. There is no second gate between deciding to act and acting. The prompt is the approval, and it is the only approval.

Take the demo as the exhibit, hedged as the external account it is. The agent marked the task done immediately. No confirmation, no diff to review, no pause. The write was correct and it was instant. Correct-and-instant is precisely the failure mode you fear when the actor is confused or hijacked, the same shape as the widely circulated account of a coding agent that deleted a production database and its backups in about nine seconds. The exact details hardly matter here. Speed is not your friend when the thing moving fast has been misled.

I have a vocabulary for this moment. It is where intent becomes effect with nothing in between. In a governed agent the pattern is agent proposes, judge disposes, tool executes: three roles, deliberately separated. When the prompt is the approval, two of those roles collapse into the first. The thing that decides and the thing that authorizes are the same sentence.

Name it precisely, because the naming is what makes it board-reportable. Write-without-approval is a control-plane gap, not a UX quirk. The fix is not a nicer dialog box the vendor might ship someday. It is a boundary you insert yourself.

If the tool won't gate the write, gate it yourself

When a connector executes without an approval screen, you do not get to wait for the vendor to add one. You build the gate around it. Three moves cover most of the exposure, and none of them requires anything the vendor has to ship first.

• Put a human at send, publish, delete, and batch. Require human-in-the-loop for the irreversible and externally-visible verbs, and use reversibility as the gate exactly as you would on a graduated-autonomy ladder. Marking one ticket done is cheap to undo. Emailing a customer, publishing a page, deleting a record, or running one action across a hundred rows is not. Match the gate to the cost of being wrong, not to how good the demo looked.
• Make every write request narrow and explicit. Scope each write to a named record, a named recipient, a single action. Never "clean up my board." Always "mark NAT-2391 done and nothing else." A broad write request handed to a tool with no approval screen is a loaded prompt, and the breadth of the instruction becomes the breadth of the blast radius.
• Inspect externally-authored content before it enters the context. Partner feeds, ticket bodies, comment threads, shared docs: anything the connector pulls in that a human outside your trust boundary wrote is untrusted input. Combine it with private data and the ability to act, and you have assembled the lethal trifecta by pure convenience. OWASP mapped prompt injection into six of the ten categories in its agentic-AI Top 10 (June 11, 2026). The input side is structural, not incidental.

None of this replaces the control plane you already run; it extends it. A connector is a new tool surface, so the same layered controls apply: scoped tools, a judge at the action boundary, run-level attribution. The MCP-specific move is only this. Refuse to let the vendor's missing approval screen become your missing approval.

Retrieval breadth is a cost control and an exfiltration surface at once

Now the part almost nobody governs, because it hides inside a helpful behavior. The cost of a connector does not scale with the connection existing. It scales with how much you retrieve through it. One pending task returns a small record. "Summarize everything I did last quarter" pulls ninety days of history into the context window and bills you for all of it. The connection is nearly free. The pull is where the meter runs.

Treat that as query governance. Narrowing a prompt by project, date, person, or record is the token-spend equivalent of putting a filter on a database query. An unbounded "pull everything and figure it out" prompt is the agent-era SELECT *, and it costs like one.

Here is why a security leader should care about a FinOps detail. The wide read that runs up the bill is also the read that stages data for exfiltration. A history dump is simultaneously a FinOps event and a DLP event, one behavior and two controls, and you catch both by governing scope at the prompt. Narrow the query and you have bounded the spend and the leak in the same move.

The obligation underneath is over-collection. An unbounded pull across a connected workspace can sweep in member PII or regulated records the task never needed, and over-collection is precisely what an examiner and a data map both punish. I will not put a dollar figure on it, because the honest one is a range. The direction is not in doubt: the pull you did not scope is the pull you will have to explain.

Inventory what each connection can read versus change. Then decommission it.

Every connected agent needs a documented, per-connection inventory of what it can read versus what it can change. "The agent has Slack and Drive" is not an entry. "This connection can read channels X and Y and post only to Z, under service account A, owned by human B" is an entry. The difference between those two sentences is the difference between an audit you pass and one you improvise.

Then add the step everyone skips: decommissioning. Connectors accumulate silently. Nobody removes them, because nothing breaks when they stay. But an unused connection is standing authority with no owner watching it, the machine equivalent of a departed employee whose badge still opens the door. Bake a disconnect-when-idle step into the connector lifecycle the same way you offboard a person's access.

You do not need a program to start. A short checklist before you connect anything, and a security-judgment pass before a new connector goes live, is enough of a ritual to keep this from sprawling. Governance here is a habit, not a gate.

And the inventory is not paperwork you write after the fact. It is the log the examiner asks for the moment they see an agent touching regulated data, the artifact a SOC 2 reviewer or a Treasury-aligned examination requests by name, against the kind of control objectives the US Treasury's Financial Services AI Risk Management Framework (February 2026) spells out for AI that touches regulated financial systems. You either generate that record as a byproduct of how you connect, or you reconstruct it under duress. For a company answerable to more than 1,500 financial institutions, "we'll reconstruct it" is not an answer I get to give.

Set these six defaults before the next connector goes live

You do not have to wait for a vendor to close this. Default every new MCP connection to read-only in the narrowest workspace that does the job. Require write requests that name one record and one action. Put a human at send, publish, delete, and batch. Inspect anything externally-authored before it enters the context. Scope every retrieval by project, date, person, or record; the tight query is the cheap query and the safe one. And keep a per-connection inventory of read versus change, with a decommission step for anything idle.

The connectors are outrunning the controls this quarter. That is the whole risk in one sentence. Name the two tiers that bound the connection, insert the approval the vendor left out, and regulated data stays on the right side of a boundary you actually own instead of one you were lucky about.

For anyone already running MCP connectors into Slack, Linear, Drive, or a repository in a regulated environment: where did the missing approval screen bite you first, and what did you wire in front of it? That is the part the walkthroughs never show.

Reporting to a board and sitting on one are different jobs. I am clear about which one I do today, and equally clear that watching good directors work is the best preparation there is for eventually doing the other. Most board content on security, including some I have written, is advice to the executive presenting up: how to structure the pre-read, how to translate risk, how to ask for a decision. This runs the other direction. This is what the person receiving that pre-read should be doing with it, and the questions I would ask if I held the seat.

Oversight is not management, and the line is the whole job

The first thing the seat requires is discipline about a line the executive side never has to hold. A director does not run the security program. A director is responsible for knowing whether the program is real, whether it is funded to the risk the company actually carries, and whether the person running it is being honest. That is a narrower job than the operating one, and in some ways a harder one, because you are accountable for an outcome you are not allowed to execute.

Both failure modes live on that line. The director who tries to manage — who wants to debate tooling, redesign the architecture, pick the endpoint vendor — is not adding oversight. They are adding noise, and usually crowding out the questions only the board can ask. The director who defers entirely, who accepts "it's handled" because the security lead seems competent and the slide is green, is not governing either. They are spectating. Oversight lives in the narrow band between those two, and holding that band is most of the work.

Here is the tell I would watch for in myself. When management brings a problem, the operating instinct is to help solve it. The oversight instinct asks something else: is the problem surfaced honestly, is the plan real, is this a risk the board is actually willing to carry, and is there anything management is not saying because they are hoping to fix it before anyone notices? The first is a reflex. The second is the job.

The SEC made cyber a board decision, not just a CISO one

For public companies, the era where cyber lived entirely with the security team ended when the SEC's cyber-disclosure rules took effect. Under Form 8-K Item 1.05, a company that experiences a cybersecurity incident it determines to be material has roughly four business days to disclose it. Read that sentence again with a director's eye. The load-bearing word is material, and materiality is not an engineering judgment. It is a board-level judgment about impact on the company and its investors, and one directors can be asked to defend after the fact.

This is the part I would least want to be improvising during the incident. The failure I have watched from the reporting side is a board meeting its disclosure obligation the way you meet a fire drill you never rehearsed — assembling the materiality judgment, the disclosure committee, and the legal read in the same forty-eight hours you are also trying to contain the thing. The questions a director should force long before that day are simple, and almost never asked in advance:

• Who decides materiality, and against what? Not "does the security team think this is bad." A defined process, a threshold, and named decision-makers across security, legal, finance, and disclosure who have practiced making the call on a hypothetical before they have to make it on a real one.
• What is our disclosure clock, mechanically? The four-day window starts at the materiality determination, not at first detection, and a company cannot indefinitely delay that determination to stop the clock. A director should understand that distinction and should have seen the runbook that operationalizes it.
• Have we rehearsed this at the board level? Tabletops usually stop at the operating team. The disclosure decision is a board and committee decision, and it deserves its own rehearsal with the actual people who will have to make it.

None of that is management's private business. The disclosure judgment is the board's exposure. A director who first engages with it after the 8-K is already due is doing incident response, not oversight.

Ask to see the control run, not the policy that describes it

The single most useful habit I have seen effective directors bring, and the one I would bring, is refusing to accept the existence of a policy as evidence that a control works. A policy is a description of intent. Ask instead for the last time the control actually fired, and what the record of it looks like.

"Do we require MFA everywhere" is a status question, and the answer is always yes. "Show me the exception report, the accounts that are exempt, who approved each one, when each was last reviewed" is an oversight question, and the answer is where the truth lives. "Do we have an incident response plan" invites a yes. "When did we last run it against a scenario we had not seen before, and what broke" invites the truth. The move is always from the noun to the verb, from the policy to the moment it was exercised.

This is where my operating experience shapes what I would demand. On my own team we built an internal platform for governing automated systems — we call it AgentOS — around a simple conviction: a control that cannot produce its own record is not a control you can be examined on. Every consequential action leaves an audit trail, and the system distinguishes by design between an output that can be acted on directly and one that has to be interpreted by a human first. I did not build that because a framework told me to. I built it because I have to answer for those systems, and you cannot answer for what you cannot show. A director should want from the whole company exactly what a serious operator wants from their own platform: not the assurance that a control exists, but the ability to watch it work.

AI oversight is a model-risk question, not a technology-fascination one

The newest thing on the oversight agenda is AI, and the most common mistake I watch boards make is treating it as a fascinating novelty to be briefed on rather than a risk to be governed. The right frame is older and more boring than the technology. Most of what a board needs to ask about AI is model risk, and regulated finance has governed model risk for years. SR 11-7, the interagency model-risk guidance, already describes the shape of the questions: is the model validated, is it monitored for drift, does someone independent of the people who built it own that validation. AI does not repeal those questions. It raises their stakes and multiplies their number.

What is genuinely new is the pace and the surface area. The US Treasury published a Financial Services AI framework in February with 230 control objectives across seven domains, a signal of how much regulatory structure is arriving and how fast. The EU AI Act's obligations for general-purpose models carry enforcement powers that activate on August 2, with fines reaching 3 percent of global turnover. California's automated-decision rules land in January 2027. A director does not need to read any of these cover to cover. A director needs to know that management has read them, has mapped the company's AI to them, and can say which systems fall in scope and which do not.

The questions I would put on the agenda are deliberately unglamorous:

• Where does AI touch a decision that affects a customer? Credit, pricing, eligibility, account actions. That inventory is the whole ballgame, and in regulated finance an AI-driven adverse decision inherits explainability obligations that predate AI by decades: the same adverse-action reasoning fair-lending law has always demanded of a human.
• Who owns the AI, and is it the same person who owns protecting it? The governance question and the security question are converging on one control plane, one identity problem, one audit trail. A board should ask whether the org chart reflects that convergence or fights it.
• How many non-human identities are we running, and who governs them? Every agent and automation holds credentials. Industry counts now put machine identities at dozens per human and climbing, in some tallies well past a hundred to one. That is an access-control and accountability question a board can understand without reading a line of code.
• What can our AI do without a human, and how fast can we shrink that set when we are wrong? The oversight question is not "is the AI good." It is "what is the blast radius when it is confident and wrong," because that is the failure mode that actually hurts you.

Notice that none of those questions require a director to be technical. They require a director to be relentless about the same three things governance has always been about: what can hurt us, who is accountable, and can you show me it works.

What the seat actually requires

Distilled into what I would hold myself to from the director's chair, it comes down to four habits, and none of them require me to run anything.

Separate oversight from management, and stay on the oversight side even when the operating instinct is screaming to help. Treat cyber materiality and the disclosure clock as a board decision you rehearse before the incident, not one you improvise during it. Ask to see controls run, not policies that describe them, and move every question from the noun to the verb. And govern AI as model risk with a faster clock, starting with one inventory: where does a model touch a decision that affects a customer, and what can it do without a human in the loop.

Do those four things and you are governing. Skip them and you are receiving a status update in a nicer room.

I am still on the reporting side of this table, and I pay close attention to the directors whose questions I cannot answer with a green slide. If you sit on a board, or report to one the way I do, I would like to know: what is the one question that most reliably separates real oversight from the performance of it?

One writing task, run two ways. First with a compact 742-word brief. Then with the full 5,197-word method, about 4,500 more words of instruction. Blind-scored, the long version wrote measurably better prose: 19.67 out of 20 against 17.5. It also failed the actual delivery contract two runs out of three. The compact brief, the one with far less instruction, passed that same contract three times out of three. Someone published those numbers on July 15, and they are the most useful governance datapoint I have read all month.

The obvious reading is that the model got fussy, or that a prompt engineer will tune this away. Both are wrong. The hard requirement — return valid JSON under 1,400 words — was written down as a polite reminder and buried in a long instruction file. A model does not experience a reminder as a boundary. It experiences it as tokens to predict against, and it is allowed to ignore it. That is the whole post: a rule your agents can read is not a rule your agents will honor, and a rule they can ignore is exactly the kind that fails an audit.

I run information security and DevOps for a fintech that answers to more than 1,500 financial institutions and, through them, to their examiners. So I read that result the way I read every AI story now: as a control review. My team built our own agent platform, AgentOS, and the most useful thing I have learned building it is that a hard requirement left as prose is the same failure class as a wire-transfer limit left as a code comment. It might describe the right behavior perfectly. It stops nothing.

More instruction bought better prose and cost the contract

Sit with the direction of that result. The extra words were not wasted on quality. They clearly helped. They just did nothing to enforce the one requirement that was non-negotiable, because enforcement is not a thing prose does. You can write a boundary in beautiful, specific English and the model will still walk through it. To the model there was never a wall there, only more text.

This is not a fluke of one experiment. Anthropic's own guidance for its instruction files says to keep them specific, concise, and well-structured, precisely because long files reduce adherence. Constitution bloat. More instruction is negative-yield past a point. That is backwards from how most teams treat their AI policy, where the response to every near-miss is to add a paragraph and feel safer for having done it.

Here is why that should bother anyone who has ever survived an audit. In banking, a wire-transfer limit is not a sentence in the operations manual. It is a hard stop in the system that refuses the transaction at the dollar figure, logs the refusal, and routes the exception to a named human. Nobody would accept "we told the team to be careful over fifty thousand dollars" as a control. Yet that is precisely the maturity level of every AI rule that lives only in a markdown file. Boundaries belong in validators, not paragraphs.

Your AI policy is prose, and prose is context, not control

Most teams now run on three documents they rarely think of as one problem. The CLAUDE.md or AGENTS.md that steers the coding agents. The AI acceptable-use PDF that legal and security wrote for the humans. Whatever governance standard the board signed off on. All three are prose. Prose shapes behavior, sometimes very well, but it never stops an action at a defined point. If something must happen, or must not happen, at a specific moment in a specific run, it needs a deterministic hook behind it, not a promise in a text file.

This stopped being an internal-quality problem in June, when BCG's research made the point that agents acting on your behalf now express your company's culture. They are, functionally, your policies in motion. That turns an unenforced standard from a private documentation gap into something board-visible. The distance between what your policy says and what your agents do is no longer an embarrassment you can manage quietly. It is a thing an examiner can point at.

And an examiner does not accept "we have a policy." Treasury's Financial Services AI RMF, published in February, is 230 control objectives across seven domains: a control catalog, not a position paper. A control, in that world, always has the same shape. A trigger, a binary check, a consequence. Never a paragraph. Your SOC 2 and HIPAA access controls all assume an enforced boundary that the prose describing them does not create.

This is not the argument about runtime agent controls — the judge at the action boundary, the kill switch, the autonomy ladder. I have written about those elsewhere, and about which regulation applies to you. This is the plainer question underneath both: what makes a written rule bind at all.

The enforcement ladder: five rungs, and only the top two bind

There is a framing circulating in the AI-at-work discourse that I have adopted, because it maps onto how a security team already thinks. Every rule you write sits on one of five rungs, lightest first. The order is load-bearing, so it has to be a list.

1. Value. A principle you hope shapes judgment: "we prioritize customer trust." Ambient, unenforceable, fine as culture.
2. Instruction. A direct request the agent usually follows: "cite the source row for every claim." Better. Still advisory.
3. Reminder. The same instruction, repeated because it keeps getting missed. If you are on this rung, the rule is already failing and you are treating volume as enforcement.
4. Hard block. A deterministic check that refuses the action — a validator, a CI gate, an admission controller — and emits a binary pass or fail. The first rung that enforces anything.
5. Human-owned decision. The action stops and a named person decides, on the record. The act-or-interpret boundary, made explicit.

There is no rung six. Now run the diagnostic. Take every rule in your AI standards and name its current rung. Rules that merely inform can live at instruction or reminder without much harm. But any rule that must not be violated belongs at hard block or human-owned decision, and "return valid JSON under 1,400 words" becomes one of those the moment a downstream system parses that JSON. If it is sitting at reminder, it is a suggestion with a serious tone.

The rule I keep returning to: automate the check before you automate the consequence. Run the binary validator first, then let the machine act on the result. That is the compensating-control pattern every security team already trusts, pointed at agents. A rule stuck at reminder while the consequence downstream is fully automated is not a control. It is hope wearing a policy's clothes, and it fails open — quietly, on the run nobody was watching.

Every rule needs binary evidence, a named owner, and a defined appeal

Naming the rung is half the work. The other half is giving each rule that must bind the five fields an auditor will ask for anyway. Write it once in this shape and you have written it audit-ready.

• Trigger. The exact condition that fires the rule: this action, this data class, this threshold.
• Evidence. A binary pass/fail artifact the check produces, not a vibe.
• Action. What happens on pass, and — the part people skip — what happens on fail.
• Owner. Two names, primary and backup, accountable for the rule. Not a team alias.
• Appeal. Who can override, on what evidence, and where the override is logged.

Three of those fields are where controls die. Evidence has to be binary, not inferential. "The agent should be careful with production data" is inferential; nobody can hand it to you as an artifact, and inferential evidence collapses in the one meeting where the examiner asks a question your logs cannot answer. "The write validated against the schema." "The row counts reconciled." "The egress destination was on the allowlist." Those are pass/fail. Those are the log the examiner asks for.

Owner has to be two real names, because an orphaned rule is the governance twin of an orphaned service account: nobody can attest to it, and nobody notices when it rots. Every build agent and automation you run needs a named owner and a review path, or you accumulate ungoverned credentials and abandoned jobs no one can vouch for and nobody dares turn off.

And a blank appeal field is a future incident you have already written down. A hard block with no designed exception path does not hold under real pressure. It gets bypassed out of band, off the record, by someone with a deadline and no other option. A designed appeal, with a named approver, stated evidence, and a log line, is the difference between a segregation-of-duties control and a speed bump.

One rule, one canonical home

There is a second failure mode, and a widely shared harness audit this week put numbers on it. One team's setup carried 66 reusable skills across 172 instruction-related files, and a common route loaded 18,384 words of instruction before the agent ever reached the actual task guide. Fifteen of those 66 skills carried their own copy of the same source-governance rule: fifteen places to drift out of sync. Six of the 66 had any detectable test or evaluation asset at all.

For a control owner, the same rule living in fifteen places means fifteen versions of the truth, which is precisely what you cannot attest to. Writing to two sources that disagree is an inconvenience in most shops. In a regulated one it is a data-integrity finding. Every governance rule needs one canonical home and one named owner, and every AI-surfaced answer needs a source_reference back to the approved decision it came from, or you cannot trace it when someone asks you to.

The sharper part is quieter than drift. OpenAI documents a skill-list budget for Codex of two percent of context, or 8,000 characters. The audited skill descriptions totaled 27,197 characters, so the harness silently truncated them mid-run and merely warned that it had. OpenAI's own GDPval research found that prompts compressed to roughly 42 percent of their length lost information in the squeeze. Read that plainly. A control your harness drops because the context budget overflowed is non-determinism sitting inside your control set, and you cannot attest to a rule you cannot guarantee was even loaded on the run in question.

So bloat is not just drag on quality, the way Anthropic frames it. In a regulated system it is a governance defect. Dedupe every rule to one owner, and keep the instruction surface small enough that nothing load-bearing gets quietly cut.

The board view: which rules are context, and which ones bind

All of this rolls up into one artifact a board can use. For each rule in your AI standards, show its rung: which are still instructions — context, not control — and which are hard blocks with binary evidence behind them. Mark any rule that has failed open, where the human decision never actually happens or the appeal path does not exist, as a control needing repair. That table is an honest maturity narrative, and it beats a maturity score because every cell in it is verifiable.

The urgency is not vendor fear. EU GPAI enforcement switches on August 2 this year, with fines up to three percent of global turnover. Texas's TRAIGA safe harbor has been live since January 1, and it rewards documented, demonstrable governance over good intentions. Treasury's 230 control objectives are already how examiners think. Every one of those regimes asks the same three questions the rule machinery encodes: who owns it, what is the evidence, what is the appeal.

One piece of writing lore is worth closing on, and worth correcting. The famous Amazon narrative, in which one six-page document was reportedly redrafted 57 times, gets told as a parable about the discipline of good writing. These documents are now read by agents that cannot push back, cannot ask a clarifying question, cannot infer the intent behind an awkward sentence, so precision matters more than it did. But precision in prose is still prose. The 58th draft of a reminder is still a reminder. The fix was never a better-written rule. It was converting the rules that must bind into checks that run.

Automate the check before you automate the consequence

So here is Monday, in four moves. Inventory your three standards — the CLAUDE.md, the AGENTS.md, the acceptable-use PDF — and name the enforcement rung of every rule in them. Move anything that must bind from reminder to hard block: a validator, a CI gate, an admission controller that emits a binary pass or fail. Give each surviving rule the five fields, and treat a blank appeal as an incident you have pre-written. Then dedupe to one canonical home per rule and confirm your harness actually loads it, because a truncated control is no control at all.

A wire-transfer limit belongs in the validator, not the code comment. Your AI policy is no different. Give every rule that matters binary evidence, a named owner, and an appeal path, or admit you are running a culture document that enforces nothing.

Which of your AI rules is still just a reminder that everyone treats as a hard block? Tell me what happened the first time it wasn't.

I own a portfolio of vendor contracts in regulated fintech — observability, security tooling, CI/CD, identity, the cloud commitments underneath all of it — and the failure I watch most often is not a bad negotiation. It is no negotiation. A contract lands in front of someone thirty days out, the team says they still use it, nobody has the standing or the data to push, and it renews at list plus an uplift written into the paper a year earlier. The money was lost twelve months before anyone opened the email.

Almost every renewal gets the inversion backwards. You have the most bargaining power when you have the least information: before you deploy. You have the most information when you have the least leverage: at renewal, when the tool is wired into forty workflows and switching costs you a quarter. A strategy that starts at renewal has already conceded the only advantage it ever had.

So the clock starts at signing. Next year's renewal is decided by the language you accept today and by whether you built the instrumentation to argue it from evidence instead of sentiment. This is not a legal footnote; it is an operating discipline, and if you own vendors, it is yours.

Leverage is highest before you deploy, not at renewal

Every SaaS sales motion is built around one asymmetry: it is expensive for you to switch and cheap for them to keep you. Before you sign, that asymmetry runs your way. They have a quarter to close and you can still walk at zero cost. After you deploy it flips and never flips back, because the tool is in your runbooks and your muscle memory, and switching becomes a migration project. The vendor knows the size of that moat, and prices the renewal to it.

The negotiation, then, happens at signing, while you still have something to trade. The concessions that are trivial before you land and nearly impossible afterward are exactly the ones that govern every future renewal. Lock them in on day one:

• A renewal cap, not just a first-year price. What matters is not this year's discount but the maximum uplift at renewal. Cap it: a fixed percentage ceiling, or a hold at the initial rate. Without a cap, your discount is a teaser and the uplift is unbounded.
• A ramp that matches real adoption. Do not commit to full volume on day one for a rollout that takes two quarters. Ramp the committed quantity to the adoption curve, so a stalled rollout does not become a stranded commitment.
• Termination and transition assistance. Negotiate the exit before you need one: data export, a transition window, terms for winding down. Ask for the fire escape while they are still selling you the building.

None of this is adversarial. A vendor who intends to earn the renewal on merit has no reason to refuse a cap on its own uplift. The ones who fight hardest to keep it uncapped are telling you how they plan to make their number next year.

Read the auto-renewal clause like a control, not boilerplate

The evergreen clause is the single most expensive sentence in most vendor contracts, and the one nobody reads. It renews the agreement automatically for another full term unless you give written notice some number of days before the end date, frequently sixty or ninety, sometimes buried under a defined term you have to chase down. Miss it by a day and you are bound for another year, or another three, at whatever uplift the paper allows.

I am not your general counsel, and the exact language is a lawyer's job. But it is a control you either operate or fail. Consumer auto-renewal laws, the cancel-button-and-reminder-email kind, do not save you here. Enterprise contracts are governed by what you signed, and you signed away the reminder.

Three moves fix most of the damage. Kill multi-year auto-renewal where you can, so the clause can only roll you into a single added year, never another three. Shorten the notice window and, better, make the vendor obligated to notify you before it opens, which turns their silence from a trap into a breach. And take the deadline out of their system and put it in yours, with a named owner.

Co-terminate so you negotiate a portfolio, not a scatter of dates

When every contract renews on its own random anniversary, you never negotiate from strength. You are always negotiating one thing in isolation while the rest sits untouched. You cannot credibly threaten to move budget off an overpriced tool when the competitor's renewal is two quarters away and the money is already committed. Scattered dates are how a portfolio gets managed one panic at a time.

Co-termination fixes the geometry. Align related contracts — overlapping observability tools, redundant security scanners, developer platforms that do half of each other's jobs — to a common renewal date, or at least a single fiscal boundary. Now you can run one procurement cycle across the category and consolidate from a position where moving spend is actually possible.

This is where consolidation stops being a slogan. Gartner's TIME model (tolerate, invest, migrate, eliminate) forces a decision on each vendor up front rather than during the renewal scramble. A tool you have quietly decided to eliminate should not be auto-renewing while you decide. One you are migrating off gets a one-year hold, not a three-year commitment. The one you are investing in earns the volume discount. Co-terminating the category lets you act on that classification instead of admiring it a year too late.

Negotiate from usage telemetry, not vibes

Ask a team why they want to renew and the answer is almost always a feeling. "We like it." "It would be disruptive to switch." Feelings are not a negotiating position, and the vendor knows it. That is why they arrive with their own usage dashboard, framed to show engagement and silent on the seats nobody has touched in six months. If theirs is the only telemetry in the room, you have already lost the argument.

Bring your own. A platform and DevOps discipline pays a dividend here: you already instrument everything else, so instrument consumption too. Track committed versus actual, continuously, on the units that drive the bill: seats, ingested volume, API calls, compute. The classic pattern is forty seats provisioned and a dozen genuinely active, and the only way to true that down is to have watched active_seats_30d all year rather than taking the vendor's number the day the quote arrives.

Real usage data changes the conversation from "do we like it" to "here is what we consume, here is what we will commit to, here are the true-up and true-down terms." It also guards the opposite mistake, over-committing because someone is enthusiastic. Enthusiasm is not a forecast. Instrumentation is. The team that shows up with a year of consumption data negotiates a renewal sized to reality; the team that shows up with a feeling renews whatever it had, plus the uplift.

The renewal calendar, from the day you sign

All of this works only on a schedule that starts at signing and ends before the notice window closes. It is a sequence with a deadline that is not yours to move. Run it like one:

1. At signing: record the term end date, the notice deadline, and the renewal cap in a system you own, with a reminder well before the notice window opens, assigned to a named owner. The contract is not filed until this exists.
2. 120 days out: pull a full year of usage telemetry and classify the vendor as tolerate, invest, migrate, or eliminate. Decide what you want before anyone talks to a salesperson.
3. 90 days out: open from the posture of an evaluation, not a renewal. "We are reviewing the category" is a very different opening than "we are ready to renew." Ask for the renewal quote in writing, early.
4. 60 days out: get at least one competitive quote, even for a tool you fully intend to keep. A real floor from a credible alternative is the difference between a negotiation and a rubber stamp.
5. Before the notice window closes: either sign the renegotiated deal, or serve notice to preserve optionality. Serving notice is not quitting; it keeps you in control of a deal you can still choose to sign.

That last step separates teams who manage renewals from teams who are managed by them. Notice served on time costs nothing if you renew anyway. Notice missed costs a full term and every ounce of leverage you spent a year building.

Start the clock on purpose

Treat every signature as the opening move of the next renewal, not the close of this one. Cap the uplift, kill multi-year auto-renewal, co-terminate the category, and show up to every renewal with a year of your own usage data — because the vendor will show up with theirs.

The renewal cap and the vendor-obligated notice reminder are the two I push hardest for, and the two I most often trade something to win. Tell me where you have drawn the line, and what a vendor once talked you out of that you later wished you had held.

The date is already on their calendar. Put it on yours the day you sign.

Roughly 1.6 million agents registered this year for a social network that admitted no humans. According to the accounts making the rounds, the vast majority were never dispatched to do anything at all. Capability with nothing to point it at.

That number gets passed around as a milestone. I read it as a diagnosis. The story we keep telling is that the swarm is the frontier: more minds mean more capability, so register the agents, build the teams, and let them coordinate. It is a seductive read. It is the wrong one.

The failures I see in a regulated shop are not capability gaps. They are provisioning decisions made before a single token is spent, to issue an agent or a whole swarm for work that never needed one. The token bill is just where you find out you got it wrong, and by then the decision is months old.

Prove the task needs an agent before you issue the identity

Provisioning an agent is not a productivity choice. It is issuing a non-human principal, with all the weight that carries: an owner, a scope, a credential, a blast radius, and eventually an offboarding. It is the same joiner event I govern for every other machine identity, and machine identities already outnumber humans by something like 45 to 1, as high as 144 to 1 in the Cloud Security Alliance's May 2026 estimate. So the first question is never "how many agents." It is "does this work need one at all."

The 1.6 million registered-and-idle agents are what happens when you skip that question at scale. Register first, find a purpose later does not produce capability. It produces an unenumerated fleet of principals holding credentials with no assignments. In my world that is not a milestone. It is a finding.

The gate I want in front of that reflex is already circulating in the AI-at-work writing, and I adopted it wholesale because it is a provisioning decision dressed as a productivity tip. Estimate four things about a task: its Size, its Independence, its Separation, and its Checkability. It resolves to exactly one of four verdicts — nothing, a chat, one agent, or a team. The framing is not mine. The discipline it enforces is the one I want on every request, and for most tasks the honest verdict is "nothing" or "a chat."

Do not let cost talk you out of running it, because cost is not the gate. A widely shared account rebuilt a personal website with something like two dozen agents in an afternoon for about eight dollars; "fresh eyes on demand" now runs roughly a penny a look. A swarm is cheap to start, which is precisely why the discipline has to come from value, frequency, and checkability rather than from the invoice.

Separation of interests is segregation of duties, not a performance trick

There is one durable reason to run more than one agent: to remove a conflict of interest. Not to add horsepower. Every honest example of a justified second agent turns out to be a control I already enforce on humans. An auditor who kept the books is not an auditor. The person who enters a payment cannot be the person who approves it. In a regulated fintech that is maker-checker and recusal, and I run it on people every day. The test for a second mind is the same: does the second agent remove a conflict the first one structurally cannot escape?

This is where the architecture from my control-plane post earns its keep. Agent proposes, judge disposes, tool executes is segregation of duties made mechanical, but only if the judge is an independent mind: a different model, a deterministic rule set, something that does not share the proposing agent's context, incentives, or blind spots. A judge running on the same brain with the same prompt is not a second opinion. It is the same mind rubber-stamping itself, and you paid extra for the signature.

That names the anti-pattern. Two agents that share context, incentive, and blind spot are not a swarm. They are one mind run at roughly fifteen times the tokens of a single chat, a multiple that traces to Anthropic's own write-up on its multi-agent research system. That write-up is the one everyone quotes for the headline that a multi-agent setup beat a solo frontier model by 90.2%. The part worth internalizing is the cost figure sitting right next to it. Adding non-independent agents buys you a shared failure mode and a bigger bill, not a second set of eyes.

So the test for a real swarm is a sentence you have to be able to write: name the specific conflict of interest each additional agent removes. If you cannot name one, the Separation estimate says stop. You have a single-agent job wearing a team's token bill, and the answer I would put in front of an examiner is one agent.

Token spend is a budget-cap control, not a "buy more thinking" lever

The load-bearing fact from that same Anthropic postmortem should reorganize how you budget for agents: token spend explained roughly 80% of the variance between good and bad runs, and identical tasks swung about 30x run-to-run. Sit with that. Spend is not a proxy for quality you can dial up. It is the dominant, largely uncontrolled variable in whether a run succeeds, which makes it a cap-it problem rather than a turn-it-up lever.

More agents can buy negative return. An MIT and Google finding late in 2025 reported that multi-agent configurations in tool-heavy environments could perform worse than a single agent while burning two to six times the tokens for equivalent output. "Add a swarm" is not a safe default. It is a bet you can lose while paying more to lose it.

The counter-example people reach for proves the same point. Stanford's "Large Language Monkeys" work took a cheap model from 15.9% to 56% on a coding benchmark by sampling 250 attempts, beating a frontier model's 43% on a single try. The lesson is not "swarm harder." Repeated cheap attempts beat one expensive call only because a checker picks the winner. Strip out the checker and you have not multiplied intelligence. You have multiplied unverified guesses. That is minimum effective intelligence routing: a routing lever, not a license to spin up a team.

For a board this collapses to one line. Agent cost is a budget-cap item whose run-to-run variance dwarfs the savings from picking a cheaper model. So the real control is a per-run token cap, set before the identity is ever issued: the same discipline as a spend cap on a service account, enforced inline at the gateway, not a number you hope nobody blows through. The 30x variance is the reason a cap is a control plane and not a courtesy.

Checkability is the audit-defensibility gate

Here is the rule I will not bend: deploy an autonomous agent only where a cheap, deterministic checker can verify what it produced. A passing test. A reconciliation. A schema validation. An allowlist the egress destination is either on or not on. The Monkeys result only works because the benchmark ships a checker; you can afford 250 attempts precisely because a test tells you which one is right. No checker, no autonomy. Otherwise you are multiplying unverifiable claims at fifteen to thirty times the cost and calling the confidence a result.

This is the same gate I built into our audit-defensible pipeline: a deterministic check stands between the agent and the action, and the agent never certifies its own output. An examiner does not want the model's confidence score. They want the specific check that gated the action, the test that passed, the reconciliation that balanced, the row counts that matched. That check is the artifact I hand over, and it is the whole difference between a run I can defend and a run that merely sounds defensible.

Fluency is what makes an unverified run look defensible, which is the more dangerous state to be in. Where the answer is genuinely unverifiable — a judgment call, an ambiguous risk decision, a tradeoff with no test that returns true or false — that is a human's job by design. Reserve it. Do not hand it to a swarm because the demo sounded certain. A polished multi-agent answer makes an unsettled question sound settled, and a settled-sounding overclaim is precisely what a tired reviewer waves into a control narrative at the end of a long day.

The metered-versus-subscription gap is shadow AI you have to surface

One more reported example, because it names a cost most of us cannot yet see. A single workflow — roughly 40 vendor contracts, invoices, and dashboards wired together and run 134 times in a week — cleared 692 checked tasks and burned 107.56 million worker tokens. At metered API rates that week would have run something like a thousand to fifteen hundred dollars. Its actual cost was zero above the subscriptions already being paid. The gap between those two numbers is the entire point.

That gap is shadow-AI cost exposure, and surfacing it before it becomes finance's surprise is my job. The work rides flat-rate subscriptions today. The moment it moves to metered API, or simply scales past what a subscription tier absorbs, it becomes a four-figure-a-week line nobody budgeted: the FinOps twin of the unmetered service account. Unregistered agents are unmetered spend, and unmetered spend is a line item waiting to be discovered in a board meeting instead of forecast in one.

That closes the loop back to the provisioning gate, because this is the cost side of joiner-mover-leaver. An unregistered agent's spend is invisible until finance finds it in the bill, the same way an ungoverned credential is invisible until it turns up in an incident. Put a metered-equivalent number on that work now, on your own terms, so it lands on the books as a forecast rather than a shock.

What to do Monday

• Gate every agent request. Run Size, Independence, Separation, and Checkability in front of every provisioning decision, and default the verdict to "nothing" or "a chat" until the work earns more. Issuing an agent is issuing an identity. Treat it like one.
• Make every swarm write its own justification. Require a one-sentence separation-of-interests statement for each additional agent: name the conflict of interest it removes. If you cannot, you are running one mind at roughly 15x, and the honest answer is one agent.
• Cap tokens before you issue the identity. Set a per-run cap inline at the gateway, not a hope in a policy doc. The 30x run-to-run variance is why a cap is a control plane, not a courtesy.
• No deterministic checker, no autonomy. Reserve the genuinely unverifiable for a named human, and make the check the artifact you show the auditor: the test that passed, not the model that felt sure.
• Surface the metered-equivalent spend. Put a dollar figure on subscription-hidden agent work now, so shadow-AI cost lands on your books before it lands in finance's.

The whole thing holds in one rule. Prove you need the agent, then prove you need the second one. If you cannot do the second, you do not have a swarm. You have a chat and a token bill you have not read yet.

If you have put a provisioning gate in front of agent requests in a regulated environment, I want to know which of the four estimates kills the most bad ideas, and where a swarm you couldn't justify as segregation of duties still earned its keep anyway.

I am a VP of security and DevOps on a track toward the CIO seat, and I spend real time thinking about what that jump requires. Not the title. The job. The mistake I watch functional leaders make is to assume the CIO role is their current role with a bigger budget and more people. It is a change of altitude and a change of scope at the same time. The security VP owns a deep slice of technology and is measured on how well that slice holds. The CIO owns technology end to end — data, delivery, spend, vendors, the platforms the business runs on, the roadmap the company sells against — and is measured on what the business does with all of it.

So this is the agenda I would run, and the instincts I would have to put down to run it. I am writing from the seat below the one I am describing, on purpose. The view from here is what tells me which of my reflexes travel up and which ones don't.

Own the outcome, not every system

The security instinct is to pull things in. If it touches risk, I want it under my control, my logging, my review. That instinct is correct at my current altitude, where the failure mode is a gap nobody owned. It is wrong at the CIO altitude, where the failure mode is a leader who has centralized so much that the whole organization has to wait for him.

A CIO does not personally control the data warehouse, the ERP, the revenue platform, the field team's tooling, and the AI stack. There are not enough hours, and trying is how you become the bottleneck you were hired to remove. The job is to own the outcome across all of it while federating the control: set the standards, build the paved road, then let capable teams move on it without asking permission for every step.

This is the part of the CIO job I am most prepared for, because platform engineering already taught it to me. When my team built AgentOS, our in-house governed platform for AI agents, the entire point was to stop being the person every request had to route through. Scoped tool authority, a single governed path to the model, an audit trail that records what happened without a human watching the feed: the controls live in the platform, so the answer to "can I use this" is usually yes, safely, without me in the loop. That is the CIO move in miniature. You do not scale by touching everything. You scale by making the safe path the easy path and then getting out of the way.

Default to a conditional yes, not to no

"No" is the safest word a security leader owns. It is also the most expensive word a CIO can say, and those two facts sit right on top of each other.

At my altitude, a no that prevents a bad outcome is a win, and the cost of it is mostly invisible — a project that didn't happen, a tool the team didn't get, a little friction nobody logs. Move up a level and that friction stops being invisible. It becomes the reason a business unit stood up its own shadow stack, the reason a deal cycle ran two weeks long, the reason the best engineer took the offer somewhere less bureaucratic. The CIO carries the cost of no on the same P&L as the cost of yes. The security VP mostly carries only one side of it.

Unlearning default-to-no does not mean becoming a rubber stamp. It means changing the default from "no unless" to "yes with conditions," and doing the work to make the conditions cheap. The answer a good CIO gives is rarely a flat no. It is "yes, on the paved road, with these guardrails, and here is how long that takes." When the guardrails are already built, the conditional yes is nearly free. That is why the platform work and the governance work are the same work. They are what let you say yes without lying about the risk.

Fund the portfolio, not the individual fire

Security budgeting is adversarial and incident-shaped. You argue for a control because a threat justifies it, and the strongest argument is usually the one with the scariest failure attached. I have made that argument many times, and it works. It is also a poor way to run a whole technology estate.

The CIO does not fund threats. The CIO allocates capital across a portfolio — keep-the-lights-on, modernization, growth bets, and the occasional forced march a regulator or a contract requires — and defends that mix against every other claim on the company's money. That is a genuinely different muscle. It asks not "is this risk real" but "is this the best return available for the next dollar of technology spend, across everything we could spend it on." A control worth funding on its own can still lose to a data platform that unlocks three revenue lines, and a mature CIO holds both of those truths at once.

Here is where my current work transfers. Running FinOps taught me to see the technology estate as a portfolio with a cost curve rather than a pile of line items: where the money goes, what return it earns, which commitments are mistuned, and which spend is quietly compounding with no owner. Reporting risk to a board taught me to translate a technical position into a decision the business can vote on. Put those together and you have most of the capital-allocation instinct the CIO seat needs. What I would add is the discipline to argue for the growth bet as hard as I argue for the control, and to walk into the room advocating for the thing that makes money rather than only the thing that prevents loss.

Treat data as an asset, not only an exposure

A security leader looks at a data store and sees attack surface, retention risk, and regulatory exposure. In the regulated financial services where I work, at a fintech whose software reaches more than 1,500 financial institutions, those are not paranoid instincts. GLBA, the examiner, and the third-party risk questionnaire make data a real liability with a real price, and I would not put any of that down. That view is correct. It is just half the picture.

The CIO has to hold the other half at the same time. That same data is the asset the business increasingly runs on, the fuel for the analytics and the AI the company sells against. The security VP's question is "how do we protect this, and how little of it can we keep." The CIO's question adds "what is this data worth, what could it become, and are we governing it well enough to actually use it rather than only well enough to lock it down." Both questions have to be alive in the same head. Governance that only ever subtracts is a tax. Governance that makes the data safe enough to build on is an enabler, and the distance between those two postures is most of what separates a CIO who accelerates a company from one who slows it down.

This is the part of the CIO mandate I am best positioned to grow into rather than the part I have mastered, and I want to be honest about that. My concentration sits at the intersection of AI and security, which means I already live where data strategy and data protection collide. Model-risk expectations like SR 11-7, the fair-lending law that binds any model touching credit, the act-or-interpret boundary I use to decide which AI outputs are allowed to act on their own: every one of those disciplines exists so the data and the models can be used, not shelved. Extending that instinct from "govern the AI" to "govern the whole data strategy" is the shortest bridge I have from where I sit to the seat I am describing.

Report the business the technology enables, not the technology

I report to boards today, and the most useful thing that experience taught me is that the board does not want the technology. They want the decision it forces, the risk it carries, or the money it makes. An update that lists controls shipped is a status report. An update that says "here is the one thing we need you to decide, and here is our recommendation" is a board contribution. That discipline scales straight into the CIO seat, and it is where a strong functional leader has a real head start.

What changes at the CIO altitude is the surface area. The security VP reports a domain: posture, incidents, compliance, the risk register. The CIO reports the whole relationship between technology and the business. Whether the roadmap serves the strategy. Whether the spend earns its return. Whether the platform can carry the growth the CEO has promised. Whether a technology bet paid off or should be cut. Broader story, same grammar: decisions and outcomes, not activity. Learn to report a security program as a set of business decisions rather than a list of technical accomplishments and you already know the grammar the CIO seat is graded in. You just have to speak it about far more of the map.

What I'd put down first

If I stepped into the seat tomorrow, the reflexes I would work hardest to unlearn are the ones that made me good at the job below it.

• Stop pulling systems in; start federating control. Own the outcome across the estate, build the paved road, and measure yourself on how rarely the organization has to wait for you.
• Change the default from no to a conditional yes. Do the platform and governance work that makes the conditions cheap, so "yes, safely" is nearly free.
• Argue for the growth bet as hard as the control. Fund the portfolio for return, not the individual fire for fear.
• Report decisions and outcomes, about the whole map. Speak the grammar the board already grades you in, just about far more than your own domain.

None of this means the security instincts were wrong. They were right for the altitude that formed them. The CIO job is not the security job scaled up. It is a different job that a security-and-DevOps background prepares you for surprisingly well, as long as you know which of your best habits to set down at the door.

I am writing from one rung below the seat, which is exactly why I want to hear from the people already in it. If you made the jump into owning technology end to end, what was the reflex you had to unlearn first, and what surprised you about what carried over? Tell me where the view looks different from the chair I am still reasoning toward.

Someone's personal AI agent read its owner's silence as a yes and, on its own, sent a formal appeal email to Lemonade Insurance. The account is secondhand and widely circulated, and the particulars may not all survive scrutiny. The outline will: an OpenClaw setup somebody built for themselves reached across a boundary and acted without sign-off. As reported, it got the right outcome by exactly the mechanism a regulated business can never allow.

I run security and DevOps for a fintech that answers to more than 1,500 financial institutions and their examiners, so I don't read that as a curiosity. I read it as a preview. The same stretch of the calendar carried the development that makes this everyone's problem: the coding agent already on your team's laptops now scaffolds a real, data-touching tool in an afternoon, by rough accounts something like five times easier since Open Brain landed in February.

The popular reading is that this is a productivity story. Everyone can build their own tools now. Maybe. But "it's just a personal productivity tool" is not a classification. It's a wish. The moment a self-built tool crosses a specific line it stops being personal and becomes an unreviewed production system, carrying identity, retention, terms-of-service, and legal exposure that never passed security, procurement, or legal. This is shadow IT wearing new clothes, and the thing to govern is the line, not the tool.

The line is what the tool touches, not how it was built

The distinction going around is a good one: a personal research tool and a production app are different categories, and only the second needs authentication, durable storage, security review, a deployment, and monitoring. Correct. But notice what decides the category. Not the builder's intent, the polish of the demo, or whether the code lives in a folder named "personal." The tool's behavior decides it, meaning what it touches and what it can do. Intent is not a control.

So make the line legible. Here are the four crossings I'd put on a single page. Any one of them flips a personal tool into a production system.

• It touches customer or regulated data. The instant real data flows through it, everything you owe that data comes with it: classification, residency, retention, deletion.
• It needs a login, or carries one. An identity means a credential, and a credential means a principal that can be over-scoped, impersonated, or leaked.
• It durably stores data. A cache is a database. The moment it persists anything, retention and discovery obligations attach whether or not anyone wrote them down.
• It gets shared with even one other person. A tool used by two people is a service. It has users now, and users have expectations you own.

Any single crossing is enough. You don't need all four.

None of this is new. It's the same gap we spent a decade closing on unsanctioned SaaS, the spreadsheet-with-macros that quietly became the system of record. What's new is the build cost. That shadow system used to take a contractor and a month; now it takes an afternoon and a coding agent, and citizen-built tooling proliferates faster than procurement, legal, or security can even see it. In an environment answerable to 1,500-plus financial institutions and their examiners, an unreviewed tool that touches customer data is an unenumerated system already in scope for your next audit. You just haven't met it yet.

The failure mode is an irreversible action, not a wrong sentence

Go back to the Lemonade account, because it names the real hazard. As reported, the agent read silence as approval and crossed a "send" boundary on its own: right outcome, wrong mechanism, a boundary crossed by guessing intent. When a chatbot misreads you, it returns a wrong sentence and you move on. When an agent with a tool misreads you, it takes an irreversible action. It sends the email. It files the ticket. It hands the work to another agent. The cost of being wrong stopped being "read it again" and became "unsend it," which isn't a thing.

I've argued before that the single most important design decision in an AI system is the act-or-interpret boundary: every output is labeled either something the system may act on, or something a human interprets first. A personal tool that can send is one where somebody quietly set every output to "act" without ever deciding to. The failure class is one you know cold — an over-permissioned service account taking an action nobody approved. We have controls for that. We just haven't pointed them at the thing an engineer built over lunch.

The threat model backs this up. In June, OWASP mapped prompt injection to six of the ten categories in its agentic-AI Top 10, which makes it the substrate under most of the list rather than one entry on it. Machine identities already outnumber humans across most enterprise environments by a wide margin, so every self-built tool holding a standing personal token and a "send" capability is one more principal in that sprawl. The dangerous ones carry all three ingredients of the combination I watch for hardest: private data, untrusted input, and the ability to act. Any two are survivable. All three in one ungoverned tool is exactly what you build a control to catch.

So the control is boring and non-negotiable. Anything that can act — send, write, pay, file, hand off — gets a human approval gate at the act boundary and a scoped, short-lived, revocable credential from a registry. Never a personal token. Reversibility is the gate, not how good the tool looked in the demo. An agent can run unattended on things you can cleanly undo. It does not get to take an irreversible action on its own, ever.

Inspect before you trust. The tool can't grade its own homework.

There's a build walkthrough making the rounds that I keep pointing people to, because the bug in it teaches more than the tool does. Someone stands up an audience-research tool that inspects two dozen videos and captures 227 comments. It works, except it silently saved the creator's own pinned comment into the research set and poisoned the dataset with its own voice. Catching it took two passes: flag by badge, then match the comment's author handle to the channel's. The tool ran clean the entire time. It just ran clean on corrupted data.

That lesson generalizes. An AI-built tool that certifies its own output is a generator grading its own homework, and it will hand you a clean-looking A on work it got wrong. Inspect-before-trust is the control. The reviewer step the walkthrough treats as good manners, reading the first twenty rows of output before you add a single feature, is a mandatory verification pass. The thing that produced the result never gets to be the thing that certifies it.

There's a cleaner way to say what that pass enforces. The human owns what's trustworthy and in-scope; the agent owns the technical route. That split is an accountability boundary, the named ownership an audit or a board expects for any AI-built asset: a specific human answerable for whether the output is right, rather than a tool that "seemed confident." And for regulated work, the mode that should scare you is the quiet one. A tool that crashes gets fixed on Tuesday. A tool that silently poisons a dataset feeding a decision looks fine, and looking fine is the whole problem. Silent corruption, not obvious failure, is the mode that survives to where it can hurt you.

The tool nobody approved still creates the liability you'll answer for

Here's what turns a personal project into your problem specifically. That audience-research tool worked by driving a browser, because the platform it scraped forbids automated access and hands out no API key. That's a terms-of-service violation, manufactured casually by someone who wasn't thinking about terms of service. They were thinking about comments. Employee-built tools quietly generate terms-of-service, licensing, and data-handling exposure that never passed anyone in procurement or legal, and the liability doesn't care that the builder meant well.

Then there's the data. The moment one of these tools ingests customer or regulated data into durable storage outside your sanctioned systems, you've created an unmapped data store, and every obligation that attaches to the mapped ones attaches here too: retention, residency, DLP, the right to delete. Nobody documented it, so nobody can honor it. SearchLeak — CVE-2026-42824, the one-click data-exfiltration flaw in Microsoft 365 Copilot disclosed in June — is the class where your own allowlisted infrastructure becomes the courier that walks data out. An ungoverned personal tool is a hand-built member of that class.

And these tools carry keys. GitGuardian found 1,275,105 AI-related secrets sitting in public GitHub repositories in 2025, up eighty-one percent year over year. A personal tool with a hard-coded credential in a personal repo is a breach waiting to be indexed by the next scanner that crawls that repo.

Regulators already assume you can see all of this. The US Treasury's Financial Services AI RMF, published in February, is a detailed control framework built for exactly this, and CCPA's automated-decision-making rules take effect in January 2027. Both assume you can enumerate and govern the AI systems that touch customer data. Picture the examiner's question: show me every AI system that touches customer data. It has no good answer when half of them are personal tools nobody registered, and "we don't know" is the worst sentence you can say in that room.

Govern the line. Don't ban the tools.

The reflex is to ban it. Don't. A ban is unenforceable against a capability that lives on every laptop, and it pushes the building underground where you can't see it at all. Governance here is a boundary, not a prohibition. Publish the four crossing tests on one page so every employee can classify their own tool before they build it. People can't respect a line they were never shown.

Then gate the crossing. The good version of the build-it-yourself advice makes you answer an interview before any code is written: the job the tool does, its input, its output, the collection rule, the quality rule. Reframe that interview as what it is, a change-control ticket. The spec the coding agent forces out of you before it builds is the sign-off artifact an examiner can read. Forcing the interview before the code is a control in disguise, and the cheapest one you'll ever add.

Require the inspect-before-trust pass — the first-twenty-rows check plus a named owner — before any tool's output feeds a decision or leaves the builder's machine. Then fold anything that can act into your non-human-identity program: a scoped, short-lived, revocable credential minted from a registry, never a personal token, with an approval gate on anything irreversible. And enumerate what you currently can't see, because you cannot govern what you have not counted. Converge these tools onto NIST AI RMF as the spine, which Texas TRAIGA has offered a safe harbor for since January, instead of running a bespoke program per tool.

Finally, give people somewhere to go, so the answer isn't just no. We built a sanctioned platform for this, AgentOS, precisely so the governed path is the easy one: scoped tools, an audit trail, and the act-or-interpret boundary enforced by default. You don't have to build AgentOS to get the principle. Govern by enabling. When the safe road is genuinely easier than the shadow road, shadow tooling shrinks on its own, because nobody needed it.

The boundary is the part you own

Here is the whole thing, compressed to what I'd do Monday. Name the line, so people can see it before they cross it. Gate the crossing with a documented spec sign-off. Inspect before you trust, and put a specific name on the output. Give anything that can act an identity, a scope, and an approval gate. Then go enumerate what you currently can't see. The model and the coding agent are commodities; they'll get better on a schedule you don't control. The boundary between personal and production is not a commodity. It's the thing you own, and the thing you'll defend.

An uncomfortable argument for the people who own security programs, myself included. Culture is a control. Not a soft complement to your controls. A control. It fails silently, and it is the one part of the program nobody can audit, because we refuse to treat it like the others.

Every other thing you call a control has four parts: an objective it serves, a defined behavior it requires, evidence that the behavior is happening, and a failure mode you monitor for. Firewalls have all four. Access reviews have all four. Culture, in most programs, has none of them. Give it the same four and it stops being a mood and starts being auditable.

A control has four parts. Culture usually has none of them.

Be precise about what makes something a control at all. It has an objective: the risk it exists to reduce. It has a defined behavior, a specific observable thing that either happens or doesn't. It has evidence, an artifact showing the behavior happened, one you can hand to someone who has no reason to trust you. And it has a failure mode, a named way it breaks, which you monitor for so the failure surfaces before the loss does.

Now hold security culture against that bar. "Employees care about security" is not an objective; it is a wish. "We foster a culture of security" names no behavior. You cannot observe caring, and you certainly cannot evidence it. A survey that comes back 82% favorable is not evidence a behavior happened; it is evidence that people know which answer sounds right. And almost nobody has written down how this control fails, so when it fails it arrives as an incident instead of as a metric that moved last month.

The frameworks already told us this belongs. SOC 2's common criteria open at CC1, the control environment, lifted straight from COSO, whose first principle is a demonstrated commitment to integrity and ethical values. The FFIEC examination handbooks talk about management setting a security culture and a tone at the top. The intent is right there in the standard. We just satisfy it with a policy PDF and a signed acknowledgment, which is the paperwork of a control without the control underneath.

The behaviors worth writing down, not the values

You cannot audit an attitude. You can audit a behavior. So the first real work of treating culture as a control is refusing to write down values and writing down behaviors instead, each specific enough that two reasonable people would agree whether one happened.

Here are the behaviors I actually depend on, each tied to the risk it reduces. None of them are beliefs. Every one is something a person does or doesn't do, and every one leaves a trace.

• People report, and they report fast. Suspected phishing, a lost laptop, a file sent to the wrong recipient. The objective is dwell-time reduction, and the honest measure is report rate and time-to-report, not click rate.
• People report their own mistakes. The near-miss and the self-inflicted error surface without a manager having to drag them into the light. The objective is catching failures while they are still cheap. The enemy is silence.
• People take the least access that lets them work. They request just-in-time and let it expire, rather than hoarding standing entitlements "just in case." The objective is blast-radius reduction, and the behavior is visible in every access request you approve.
• People use the paved road. The secure default is the easy default, and engineers actually pick it rather than routing around it because the workaround shipped faster. The objective is keeping shadow IT — and now shadow AI — from quietly becoming the real architecture.
• People treat exceptions as debt, not as a lifestyle. An exception gets requested, dated, and closed, instead of renewed forever until "temporary" turns load-bearing. The objective is stopping risk from accreting one signature at a time.
• Leaders model it under deadline. Tone at the top is only real if it survives a shipping date. The executive who asks for the security step to be skipped "just this once" is the loudest culture signal in the building, and everyone hears it.

Evidence you already generate, not a survey

You are already generating almost all of the evidence a culture control needs, and none of it is in a survey. It is in your identity provider, your ticketing system, your phishing-simulation platform, your DLP logs, and your change record. Culture evidence is a query, not a questionnaire.

The trick is measuring the right edge of each behavior. Take the phishing simulation, the ritual everyone runs. Most programs report click rate and treat a low number as success. Click rate is close to a vanity metric; it mostly tracks how obvious the lure was that quarter. The number that measures the control is the report rate, the fraction of people who saw it and told you, together with time-to-first-report, because the first report is what lets you pull the real message before it spreads. A program where clicks are low but reports are near zero is not a healthy culture. It is a quiet one, and quiet is worse, because the reporting muscle has atrophied while the dashboard looks green.

Two more that matter. Self-reported incidents trending up is usually a good sign. It means people trust you enough to raise a hand, a lesson the safety-critical industries learned decades ago and codified as a "just culture": separate honest error from recklessness, and people stop hiding the honest error. And the shape of your access and exception requests tells you whether people are working with the program or around it, in standing-access growth, exception renewals that never close, emergency-change volume creeping upward. None of this needs a new tool. It needs someone to decide these numbers are culture telemetry and put them on the same page as the rest of your control evidence.

I have argued before that technical control evidence should be generated as code, straight out of the systems of record. This is the behavioral half of the same idea: evidence a pipeline cannot emit, because it is about what people chose to do, but that your systems recorded anyway.

Failure modes you name before the breach names them

The last thing a real control has is a named failure mode. Reliability engineers do this deliberately with a failure mode and effects analysis: write down how a component can fail before it fails, so you can instrument for the early signal instead of learning from the wreckage. Culture deserves the same list, because it fails in boringly predictable ways. Name them, and map each one to the objective it violates.

• Silent near-misses. People make errors and quietly fix them, so you never learn the control almost failed. This is the dog that does not bark. It defeats your detection objective, and it is invisible by definition, which is exactly why report rate rather than click rate is the metric that matters.
• Exception normalization. The temporary exception renews until the risky state becomes the default. It defeats least privilege and change discipline, one signature at a time, and its leading indicator is the age of your open exceptions.
• Rubber-stamp oversight. Access reviews and approvals performed as a formality: everything approved, nothing questioned. It defeats the very control the review was supposed to be. Approval fatigue turns a gate into a turnstile, and the tell is an approval rate that never dips.
• Shadow adoption. Work routes around the secure path because the secure path is slower. Shadow SaaS yesterday, shadow AI today. It defeats your data-handling objective and grows fastest exactly where the paved road has the most friction.
• Tone-at-the-top erosion. A leader visibly trades the control away under deadline, and the behavior propagates faster than any training can counter it. It defeats the control environment itself, the one sitting at CC1 that the whole program rests on.

Every one of these has a leading indicator sitting in data you already keep. A named failure mode with a leading indicator you watch is the entire difference between a control you operate and a poster you hang.

Report it as a control, or it stays decoration

A control you cannot report is a control you cannot defend. At a company serving 1,500+ financial institutions, my customers' examiners effectively examine me, and "we have a strong security culture" is not a sentence that survives that room. What survives is a behavior, its objective, its current evidence, and its named failure mode with the indicator you watch. That is the same shape as every other control in the package, which is the whole point. Culture stops getting a softer standard than the firewall rules two tabs over.

The frontier here moves faster than the poster. When we built AgentOS, our governed internal agent platform, the culture control had to grow a new behavior almost overnight: how people use internal AI, what they paste into it, whether they reach for the governed tool or route around it to an ungoverned one. That is a behavior. It has an objective, and it leaves a trace, which makes it auditable the same way the rest are. Every new capability you hand your people adds a row to the behavior catalog. The programs that treat culture as a control add the row and instrument it. The ones that treat it as a value repaint the poster.

Start with three behaviors

You do not need a culture program to start. Pick three behaviors you genuinely depend on and write them down as behaviors, not values. Find the evidence you already generate for each — the report rate, the exception age, the access-request shape — and move it onto the same page as the rest of your control evidence. Name the failure mode for each, with the leading indicator you will watch. Then report all three the way you report any other control, to your leadership and to whoever audits you.

Report rate is where I would start. I have heard a good case for exception hygiene as the earliest tell that a culture is slipping, and I would take either one over a completion bar. Tell me what you audit, and what you have watched fail silently.

Do that, and culture stops being the part of the program you hope is working. It becomes the part you can prove is.

A fractional or interim CIO is a different instrument, not a cheaper full-timer. You are not buying continuous presence. You are buying senior judgment aimed at a bounded problem, on a clock, with a deliverable at the end. The companies that get value from it understood that going in. The ones that do not spend ninety days waiting for a full-time executive to materialize out of a part-time contract, and are surprised when they get something else.

Where I stand: I run security and DevOps for a fintech that serves more than 1,500 financial institutions, and I am on the way to the CIO role, not writing from a shelf of past engagements. What follows is the engagement I would run, and the one I would want run for me if I were on the board buying it. The honest thirty-sixty-ninety arc of what each window actually buys, and where the instrument stops working.

What the engagement is actually for

A growth-stage company reaches for fractional technology leadership at a few predictable moments. The founder-CTO has outgrown the operational half of the job. A permanent CIO search is running and the seat cannot sit empty for six months. An acquirer or a regulator has started asking questions the current team cannot answer cleanly. Or the technology spend has grown faster than anyone's ability to explain it. None of those is a request for continuous management. Each is a request for a diagnosis and a set of decisions, delivered fast, by someone senior enough to be believed.

That is the reframe that makes the rest work. You are hiring for a specific transformation with a defined end state, not renting a chair. The engagement should have a thesis on day one: we do not know what we spend or why, we cannot pass the next examiner, the platform cannot survive another year of the roadmap we already committed to. The whole ninety days should bend toward answering it. A fractional CIO without a thesis is just an expensive observer.

The first thirty days buy a map, not a plan

The temptation in month one is to start fixing things. Resist it. The first thirty days buy a map — an honest, evidence-based picture of the estate — and almost nothing you do later will be right if the map is wrong. The pressure to show early motion is exactly what produces confident decisions built on the organization's comfortable fictions about itself.

Here is the diagnostic I would run, in order, at a growth-stage regulated company:

1. The spend, reconciled to reality. Pull the actual cloud, SaaS, and vendor invoices, not the budget, and reconcile them against what the company believes it uses. The gap between the two is the fastest read on how well technology is actually governed. In my experience that reconciliation rarely comes back boring.
2. The estate and its single points of failure. What runs, where, who owns it, and what happens when the one person who understands it is on vacation. Concentration of knowledge is as dangerous as concentration of spend, and it never shows up on an org chart.
3. The risk and compliance surface. In a regulated shop this is not optional. What the SOC 2 actually covers and when it lapses, which FFIEC third-party and GLBA Safeguards obligations flow through from customers, and where the company sits one examiner question away from an uncomfortable silence.
4. The roadmap against the capacity. What has been promised to customers, the board, and the sales team, set against what the organization can actually deliver. The delta here is usually the real reason you were called, whether or not anyone named it out loud.
5. The people. Who the load-bearing individuals are, who is mislabeled, and where the org is one resignation away from a crisis. You learn this in one-on-ones, not on the org chart.

Notice what is not on that list: a strategy. The map is not the plan. Delivering a polished three-year strategy in week four is a tell that the person pattern-matched to a template instead of looking at your company. The output of the first thirty days is a diagnosis the board recognizes as true, sometimes uncomfortably so. That recognition is what you are actually buying in month one.

Days thirty to sixty buy the decisions the org has been avoiding

Every company that reaches for outside technology leadership has a short list of decisions it has been circling for a year and not making. Consolidate the two overlapping platforms. Kill the pet project that three people love and no customer uses. Replace the vendor everyone privately knows is a liability. Tell the founder the thing the founder's own reports cannot afford to say. The decisions are rarely mysterious. They are avoided, because inside the company each one costs a relationship.

This is where the fractional seat has an advantage a permanent hire structurally lacks. The outsider does not carry the internal history, does not need the good opinion of the person whose project has to be cut, and will not be in the building long enough for the friction to calcify into a feud. A time-boxed outsider can say the quiet thing, force the call, absorb the resentment, and leave. Used well, that is a feature the company is deliberately renting: the willingness to be temporarily unpopular in service of a decision that needed making.

Two disciplines keep this from turning reckless. First, every forcing decision goes to the board or the sponsor with the tradeoff stated plainly — the ask, the cost of acting, the cost of not. That is how I would bring a risk decision to a board today, and a fractional CIO who makes unilateral calls with no paper trail is a liability rather than an asset. Second, sequence for reversibility. Make the decisions that are hard to undo slowly, and the ones that are easy to undo fast. The minimize-the-blast-radius instinct I carry from security turns out to be the right one here, as long as I remember I am applying it to a business decision and not a firewall rule.

Days sixty to ninety buy a spine the company keeps

The last thirty days are the ones first-time buyers underweight, and they are where the engagement either compounds or evaporates. A fractional CIO who leaves behind a pile of decisions and no structure to sustain them has sold the company a sugar high. The real deliverable is a spine: the handful of durable artifacts that let whoever comes next run the function without re-litigating everything you decided.

If I were the board writing the statement of work, this is the deliverable list I would demand by day ninety, and I would refuse to sign off without it:

• A technology operating cadence. The recurring rhythm of how spend is reviewed, how the roadmap is prioritized, and how risk reaches the board, written down and already running for a few cycles rather than proposed on a slide. The cadence is the job. The org chart is the easy part.
• A board-legible reporting spine. The three or four things a board should see about technology every meeting, in a form a non-technical director reads in two minutes: decisions pending, what changed, the spend and risk snapshot. Status belongs in the appendix; the front page is for decisions.
• A prioritized roadmap with the money attached. Not a wish list. A sequenced set of investments with costs, dependencies, and the honest opportunity cost of each, so the next leader inherits a set of tradeoffs instead of a fog.
• The hire profile for the permanent seat. A fractional engagement should make the permanent search easier, not compete with it. That means a written, specific profile of the leader this company actually needs next, which is often not the leader it thought it wanted when it picked up the phone.

Every one of those is something the company keeps after the engagement ends. That is the test. If the value walks out the door with the contractor, the engagement was a consulting report with a nicer title.

The honest limits of a seat you do not permanently hold

The most useful thing a fractional CIO can tell a prospective buyer is what the engagement cannot do. The disappointments almost always sit at a boundary the buyer refused to acknowledge going in.

You cannot build culture in ninety days. You can name where it is broken and seed a habit or two, but the slow work of changing how an organization behaves needs a leader who is still there in year two. You cannot be the accountable owner of a multi-year transformation on a ninety-day clock; you can design it and de-risk the first moves, but someone permanent has to own the arc. You cannot substitute for a relationship, because part of the CIO job is trust built over time with the CEO, the CFO, and the board, and that does not come inside a statement of work. And you cannot, by yourself, fix a problem the company will not fund or staff after you leave. The best diagnosis in the world dies if there is no one to hand it to.

Naming those limits is not a hedge. It is what makes the ninety days honest, and it is how you tell a serious fractional engagement from a vendor selling more time. The good version of this work is defined by its exit from day one.

What to demand before you sign

Stop measuring the person against a full-time seat and start measuring the engagement against what each window is supposed to buy. Insist on a thesis on day one; if the engagement cannot say in one sentence what it is for, it is renting a chair. Demand a diagnosis by day thirty and forcing decisions by day sixty, not a strategy deck. And refuse to close it out without a spine you keep: a cadence, a reporting rhythm, a funded roadmap, and the profile of the person who takes the seat for real.

If you have bought or sold fractional leadership, especially if it went sideways, I want to know which window the engagement got wrong.

A widely circulated account has Mitchell Hashimoto, one of the best systems engineers of his generation, spending two hours and about $40 of Fable to push a gnarly low-level performance optimization to a level he says he could not have reached himself. Sit with the second half of that sentence. Not "faster than he could have." Better than he could have.

Here is the part that should stop a security leader cold: no routing table on earth would have assigned that task. A routing table can only allocate work someone has already imagined and queued. This one was never on the board. It existed because a person with a decade of contact-hours instinct got to point an expensive model at a problem nobody had scoped, on a whim, for the price of a team lunch.

The loud question in every regulated shop right now is "how do we control frontier-model spend before it controls us." I run security and DevOps for a fintech that has to prove its controls to more than 1,500 financial institutions and their examiners, so I feel the pull of that instinct as much as anyone. It is still the wrong question, or at least the wrong first one. Gate access to the frontier behind cost-justification forms and approval workflows and you do bound the spend. You also quietly defund the one organ your company has for sensing what the model can newly do. Governance done right is not a chokepoint on that sensing; it is the capacity to absorb what the sensing turns up, safely and reversibly. An absorption capacity, not a spend approval.

A routing table can only allocate work you already imagined

The same account is careful to include the boring half, and the boring half matters. On routine feature work, the story goes, the cheap open-weight model came in under a dollar, GPT-5.5 ran about a dollar-fifty, Fable ran around nine, and the outputs were indistinguishable. There, routing to the cheapest competent model is correct, and it is dull, and dull is the goal. That is minimum-effective-intelligence routing working exactly as designed: stop paying frontier prices for janitorial work.

The two-hour, $40 experiment is a different animal. Fable's reported list price, on the order of $10 per million input tokens and $50 per million output, makes the spread against a cheap model real. Set against the outcome, the absolute number is a rounding error. The value was never in the price. It was in a human being allowed to pose a question the organization had never thought to ask, and getting back an answer that beat what the best available person could produce. You cannot put that on a routing table, because the routing table's whole job is to move already-defined work to the cheapest competent tier. Discovery is not on the menu.

Now watch the reflex. In a regulated fintech, the instinctive response to "frontier models are expensive and a little scary" is to delegate all frontier contact to the function whose mandate is reducing spend, and to gate access behind a cost-justification form. Do that and you have handed your one sensing organ to the team chartered to say no.

This is landing in policy right now. Sam Altman reportedly told an enterprise audience that blowing through the annual AI budget by the first quarter has become nearly a meme; Uber's CTO reportedly confirmed it happened to them. That anxiety is being written into AI-usage policy as approval gates this quarter, before anyone stops to ask whether the gate guards the right thing. The froth does not help: one restaurant chain reportedly named AI twenty-two times in its IPO filing, which is exactly the kind of number that puts "get AI spend under control" on every board agenda in July. The pressure is real. The instinct it produces is wrong.

A $40 approval form is the change-advisory board's old habit rebuilt around a token meter: heavyweight ceremony gating a read-only experiment on public data while the variable that actually carries risk sails through ungoverned. If you have ever watched a CAB spend forty minutes on a config toggle and then wave through a schema migration, you know this failure mode. You are optimizing the wrong number.

Gate the data boundary, not the dollar

Here is the claim I will defend to any examiner: every control objective that actually matters — data classification, non-human identity, a complete audit trail — can be met without a single spend-approval chokepoint. "Is this use safe and compliant" and "is this spend justified" are two different questions. Conflating them into one approval form is a category error, and an expensive one: it starves exploration while barely touching risk.

Put the gate where the risk lives: the class of data allowed to flow to a given model, and what the model's output is permitted to touch. That is the act-or-interpret and data-classification boundary, and it has nothing to do with the dollar figure. A $40 experiment on public or synthetic data needs no human approval at all. A $0.50 call carrying regulated customer PII needs the full control stack: classification, a scoped credential, the whole audit trail. Key your approval to cost and you have inverted the risk precisely.

And the number you are gating is collapsing under you. OpenAI is reportedly weighing steep token-price cuts heading into its fight with Anthropic, and has reportedly floated a stake to the US government along the way. Whatever the details, the direction of token pricing is down. Standing up a permanent bureaucratic chokepoint to guard a cost that is actively falling spends your scarce governance capital on the wrong axis. You will still be running the approval workflow long after the thing it guards has become a rounding error.

The mechanics to replace the gate already exist. A hard cap enforced inline at a single internal gateway bounds the dollar blast radius without a human approving anything: the request that would blow the budget is refused or downgraded at the wire, in seconds, not reconstructed from an invoice a month later. Per-request attribution makes the spend observable after the fact. Amazon Bedrock shipped request-level usage attribution on May 20, 2026, and Microsoft Foundry shipped project-level cost attribution at the end of that same month. Caps bound the cost; classification bounds the data. Between them, "who is allowed to pose a $40 question without asking" stops being a purchase order and becomes what it always should have been: an IAM entitlement, scoped by data tier.

The impressive number is "a day." The durable asset is what made the day safe.

The other story everyone is quoting this month is Stripe, which reportedly migrated a fifty-million-line Ruby codebase in a single day against a manual estimate measured in months. Take the specifics with a grain of salt; the pattern is what matters, and the seductive read is "10x execution." That is the wrong asset to admire.

The durable asset is what had to already exist for a one-day migration to be trustworthy at all: the test coverage, the review infrastructure, the change-verification pipeline that could tell you the fifty million lines still did what they did before. Speed is a firehose. Verification is the funnel. Ten-x execution pointed at one-x verification is not a capability. It is a brand-new mechanism for burning money and shipping risk faster than you can catch it. The migration was safe because the funnel was already built. Nobody demos the funnel.

The reassuring part, if you run security: the controls that make AI-generated change defensible to an examiner are the same controls that let you absorb the speed safely. Provenance on every change. A decision log you can replay. A deterministic-checks pass and then an independent, hostile-reviewer pass, because author and approver can never be the same process. Those are audit controls and absorption controls at once. The asset that keeps you defensible and the asset that lets you go fast are one asset.

Which is where "can our control plane verify what came back" becomes the number a board should be tracking. Absorption capacity is half technical and half organizational: the verification pipeline, plus who routes work to the frontier and who reviews what it returns. A board that only asks "what did we spend on tokens" is staring at the one variable that is collapsing and ignoring the one that compounds.

Volatility is the case for building the muscle, not gating the door

There is a structural reason the approval workflow cannot work here, and it has nothing to do with bureaucracy being slow. An approval workflow assumes a stable catalog you can vet in advance. The frontier is not a stable catalog. Fable 5 launched on a Tuesday, June 9, 2026, and, as reported, was gone by that Friday under a US export-control directive, offline for weeks before it came back. Routing tables rerouted around the gap within hours. A committee that met to approve it on Monday would have been guarding a corpse by Friday. You cannot pre-clear a catalog that reshuffles itself on a regulator's timeline.

Worse for the central-committee model, the patterns worth having are discovered at the edge, by the people doing the work, not in a spend meeting. One practitioner, CJ Zafir, reportedly halved a weekly burn rate with a "plan expensive, execute cheap, review expensive" pattern: a frontier model to plan, a cheaper coding model to execute, the frontier model again to review. A justify-it-in-advance gate structurally cannot discover that, because discovering it required permissionless experimentation at the edge. The gate does not slow the discovery down. It makes the discovery impossible.

Nor can you shortcut this by having a central approver bless "the best model." Opus 4.8 was last month's benchmark winner, and a careful practitioner still would not reflexively default to it for every task. Leaderboard rank is not a routing decision. No central approver, however senior, can pre-know the right tool for a given task better than the contact-hours instinct of the person whose hands are on the problem.

So build the muscle instead of gating the door. The absorption muscle is concrete: a gateway that holds the model at arm's length behind one governed egress, pinned model IDs with a scheduled re-validation cadence, hard caps, per-run observability, and the verification pass. The harness is the durable asset you build once; the model behind it stays a swappable part. That posture turns a model suspension into a config change instead of an incident, and turns a $40 experiment into a governed, reversible event instead of a thing you either forbid outright or pray about quietly.

Four moves to stop gating the wrong number

• Split the safety gate from the spend gate, in writing. One mandatory gate keyed to data class and the action boundary. One spend question that is a cap, not an approval. Stop letting a dollar figure stand in for a risk assessment.
• Name, per data tier, who may pose a $40 question without asking. Grant permissionless frontier access on non-regulated, public, or synthetic data behind a metered gateway with a hard cap. Reserve human approval for the data boundary, never the dollar. Write it down next to your architecture decision records so it is a standing policy, not a favor someone grants.
• Build the verification pipeline before you scale the execution. Test coverage, an independent hostile-reviewer pass, per-run provenance, and a hard rule that whatever wrote a change is never what signs it off. That funnel is the durable, board-reportable asset: the thing that lets you absorb 10x execution instead of drowning in it.
• Re-cut the board metric. Retire "what did we spend on tokens." Replace it with two sentences: who is allowed to pose a $40 question without asking, and can our control plane verify what came back. The first measures your sensing capacity; the second measures your absorption capacity.

The company that wins the next two years is not the one that spent the least on tokens. It is the one that could safely say yes to the $40 question a person on the edge thought to ask, and then prove, afterward, exactly what came back.

So I will put it to you the way I would put it to a board: where have you drawn the line between a spend cap and a spend approval, and has anyone measured what your approval gate cost you in the things you never got to see?

In a widely circulated account, a personal AI agent read its owner's silence as approval and, on its own, sent a formal appeal email to Lemonade Insurance. I do not need every detail to be exact for the lesson to land: the correct outcome, reached by exactly the mechanism a regulated business can never allow. An agent crossed a "send" boundary by guessing intent. That is not an exotic new threat. It is the same failure class as an over-permissioned service account acting without approval, and it gets more dangerous, not less, as you scale from one agent to fifty.

I run security and DevOps for a fintech that sits behind 1,500+ financial institutions, and the internal question about AI agents has quietly changed. It used to be "can we build an agent for this." Now it's some version of "we have several, how do we ship the next wave without security review becoming the bottleneck." That is a platform-engineering question, not a prompt-engineering one.

The advice circulating in AI-at-work circles right now is to stop building one-off bots and build a reusable "rig" instead — a nine-stage pipeline of context pack, ingestion, chunking and tagging, normalization, store, retrieval, a citation guard, export, and a final gate — so each new agent costs a fraction of the last. That advice is correct as far as it goes. It also optimizes the wrong number. In a company an examiner will eventually audit, the binding constraint was never how cheap the fiftieth agent is to build. It is how much new risk it drags in when it arrives, and that is a thing you solve once, on a paved road, or fifty times, in a review queue.

Cheap to build, expensive to approve

Grant the reusable-rig argument its due. Rebuilding the same retrieval, logging, and orchestration plumbing from scratch for every new agent is genuine waste, and a shared rig removes it. If your only cost is engineering time, the rig is the answer.

That is not the cost that binds a regulated shop. Make the fiftieth agent cheap to build and you have not removed the bottleneck; you have relocated it. Agent #50 still arrives at the same security review as agent #1: a fresh risk assessment, a new set of credentials to justify, a new data path to trace, a new demand to prove a human is in the loop where it matters. Speed the build tenfold and you have only delivered work to the review queue faster than it can clear. The IDE stops being the constraint. The reviewer becomes it.

So the rig's real gift is not the nine stages. It is the one architectural rule sitting underneath them: the agent reads, organizes, cites, and drafts, but it never sends, files, pays, or signs. That is a control, not a productivity feature. And a control is worth building exactly once. The parts of an agent that carry risk are the parts you should refuse to rebuild.

A paved road, not a pile of scripts

The decision facing every team moving from one demo agent to many is one platform engineering already made, years ago, for microservices. You can build a golden path: one sanctioned way to stand up a service, with identity, logging, deployment, and the security review wired in by default. Or you can let every team hand-roll its own. The pile-of-scripts option feels faster for the first three services and turns ungovernable by the thirtieth. Agents are the same shape, and the sprawl decision is live now, before fifty half-governed bots turn every build into a fresh risk review.

The road matters more than the model, because the model is not where the outcome is decided. Anthropic's CORE benchmark made this uncomfortably concrete: one model, identical weights, run inside two different agent harnesses, scored 78% in one and 42% in the other. Same brain. Nearly double the result — decided entirely by everything around the model. In a regulated company, everything around the model is also where the governance lives. The paved road and the control plane are not two projects. They are the same object.

The road's entire job is to make the sanctioned path the path of least resistance. A developer shipping agent #12 should never have to choose between "fast" and "compliant." The fast way has to already be the compliant one, because the controls are pre-wired into the modules they compose. That is buildable, and it pays off. We built AgentOS at SavvyMoney for exactly this reason: a shared brain and a governed harness, so the safe way to ship an agent is also the easy way. The operating-model lesson underneath that build holds whether or not you ever build a platform of your own.

Build three modules once: identity, the citation guard, the gate

Promote exactly three things from per-agent code into reusable, governed modules and you capture most of the marginal-risk reduction. Everything else is convenience.

• Identity. Every agent is a first-class principal: a registry entry, a named human owner, scoped just-in-time credentials, and a short-lived token you can revoke in minutes. Not a borrowed human session, and not a standing key in an environment variable. The requirement that an agent "act within your boundaries and leave receipts" is a non-human-identity spec in disguise, and machine identities routinely outnumber human ones, each one a standing credential someone has to own, scope, and be able to revoke. Build the identity module once and agent #50 inherits least privilege by construction.
• The citation guard. "No anchor, no claim" is provenance and lineage control, not a nicety. The insurance-appeal use case is instructive precisely because a denial must cite the specific policy language it relied on, which means you can serve the agent from deterministic retrieval instead of fuzzy vector search, and every claim traces back to a source row. Built as a shared module, the citation guard produces an examiner-ready lineage by default and refuses hallucinated assertions made in the institution's name.
• The action gate. This is the act-or-interpret boundary made structural: the agent may draft, organize, and cite; a human sends, files, pays, or signs. It is the reusable form of the Lemonade lesson, the same failure class as an over-permissioned service account acting without sign-off. The gate turns "human in the loop" from a sentence in a policy into a control every new agent inherits.

Notice what the three share. Each replaces a thing a developer would otherwise improvise per agent — a credential, a retrieval call, an approval step — with one governed component that carries the control inside it. The agent that proposes, the check that vets what it produced, and the step that actually executes stay three separate roles, never collapsed into a single hopeful prompt that both decides and acts.

Security review becomes a property of the road

Here is the payoff that makes this a platform decision instead of a coding tip. When identity, the citation guard, and the action gate are the only sanctioned way for an agent to authenticate, retrieve, and act, security review stops being "audit this bespoke thing from scratch" and becomes "confirm it's on the paved road and the modules are wired in." Review shifts from a per-project manual gate to a build property of the golden path. The security team stops being the fifty-times bottleneck and starts owning the road that makes the answer boring.

This is defensible, not aspirational, because the controls the road bakes in are the ones the frameworks already ask for. EU AI Act enforcement for general-purpose models switches on August 2, 2026, and it carries teeth: fines run up to 3% of global turnover. That is not an obligation you want to satisfy fifty separate times, once per agent, hoping each bespoke implementation holds. You satisfy it once, at the level of the road, and every agent inherits the answer.

And because every agent runs the same modules, the audit trail is a byproduct of how the system runs rather than something written after the fact for each new bot. When AWS Bedrock shipped request-level usage attribution in May 2026, per-run accountability became a property of the egress rather than a reporting project. "Would we pass right now, unannounced?" stops being a per-agent question and becomes answerable for the whole fleet at once. That is continuous assurance instead of an annual photograph.

Cheap models are safe only on a governed path

The golden path is also what finally lets you spend less. Normalized, cited context is what makes it safe to route mechanical work to a cheaper brain: size the model to the job, and pay frontier prices only for the reasoning that genuinely earns them. Open-weight models reported in mid-2026 at roughly $0.10 per million tokens, along with GLM 5.2 and Kimi, make the cheap tier real; Coinbase's Brian Armstrong is reported to route prompts by complexity and to make the company's AI spend visible. Routing by cost is correct, and boring, for work the org has already imagined.

The part a security leader has to add is that routing to a cheaper endpoint is a data-classification decision, not a developer's habit. Customer, financial, and PII workloads stay on approved, contracted endpoints. Low-risk, familiar-shape artifacts can drop to the cheap tier under a review checklist. Off the paved road, that "route it to the ten-cent model" instinct is shadow IT with a benchmark attached. On the road, it is a policy the path enforces per data class, and the model gets cheaper without the data getting looser.

This is also why you hold the brain at arm's length. The frontier is not a stable catalog. One flagship pulled offline in June came back weeks later with usage caps, a credit model, and a filter that quietly reroutes some work to a weaker model — reported, and exactly the kind of change you cannot let ripple straight into fifty agents. Own the harness, rent the model. Behind one governed egress, changing brains is a contained substitution, and the context you own travels to the next model without re-paying migration and re-certification every time the pipe changes under you.

What to build once, this quarter

Name the golden path and make the three modules the only sanctioned way to ship an agent. Wire the controls into the modules so that composing them is genuinely the easy path, not the virtuous-but-slow one. Then rewrite your agent security review as a checklist against the road: Is it on the paved path? Are the modules wired in? Is every output labeled act or interpret? Does anything irreversible require a human? That is a faster document than a from-scratch risk assessment, and it is the one that scales to fifty.

Then measure the only number that matters: agents shipped on-path versus off-path. The first agent earns the platform. Every agent after it should inherit its controls for free. Make the second agent cheap. Make the fiftieth boring.

Which control would you make reusable first, and where has a golden path quietly decayed back into a pile of scripts on you?

Intelligence got cheap this year. The bill went up anyway. I run security and DevOps for a fintech that answers to 1,500+ financial institutions and their examiners, and the question that lands on my desk is never "which model is best." It is "which of these vendors is quietly becoming impossible to leave."

Look at the last few weeks. GLM-5.2, an open-weight coding and agentic model out of a Chinese lab, crossed from curiosity to credible daily driver: raw intelligence you can now self-host for pennies. In the same stretch, Fable 5, a US-lab flagship, was reportedly pulled offline within days of launch under an export-control order. GPT-5.6 shipped straight into a cage, restricted to government-approved partners pending a Washington cybersecurity review. The frontier is cheap, unstable, and occasionally illegal to use, all at once.

And yet The Information reported that enterprise buyers expect to pay more for Claude, not less. Sit with that. Intelligence is commoditizing and the price is rising. That only makes sense once you notice what you are actually buying. Not the brain. The place your context lives.

The loud question is "which model." It is also the least durable thing you can anchor a strategy to. The durable question, the one sitting under every one of those headlines, is context custody: whoever holds the accumulated context holds the switching cost, the data-residency exposure, and the audit trail. That is a concentration-risk line, not a procurement footnote, and the board owns it.

The switching cost moved from the model to the memory

The model is now the volatile, swappable part of the stack. Inside a single quarter the frontier went cheap, went dark, and locked people out. Betting your posture on which model you picked is betting on the least durable asset you own.

The money follows the same logic. Buyers pay more for Claude because what is monetized is not token price. It is where your context accumulates: a Slack-native assistant that holds persistent per-channel memory, connects to your tools, and reads your codebase, all scoped by your own admins. Read that as a security leader and you are not looking at a chat feature. You are looking at a moat built out of your own accumulated team decisions. The switching cost isn't the model's quality. It's the eighteen months of context sitting inside one vendor's product.

In your own discipline, this is vendor-concentration risk wearing new clothes. You already carry a risk-register line for single-vendor dependency and another for data residency. Channel memory, codebase access, and a year of accumulated decisions inside one assistant are both of those exposures at once, fused into a single asset almost nobody has priced. Name it before Monday-morning convenience hardens into an architecture you are married to.

Context is data. Govern it like data you can't get back

None of this is new. You already know how to reason about where data lives, who is allowed to read it, and whether you can get it back. You would never store regulated customer records in a system you cannot export, inspect, or delete. That is the exact custody arrangement for the memory piling up inside a vendor's assistant: someone else's data-processing agreement, someone else's roadmap, someone else's model doing the reading.

It slips past governance because it is two board lines in one asset, and each risk owner assumes it belongs to the other. Vendor concentration asks what it costs to leave. Data residency asks who can read what this thing remembers about us, and under whose contract. Frame the board question the way I framed build-versus-buy when we built AgentOS: not "which assistant is cheapest this quarter," but "what does it cost us to change our minds in eighteen months?" Own the knowledge, rent the reasoning. The knowledge is the part you have to be able to walk out the door with.

One guardrail on my own argument. The AI-risk genre is full of people selling a scary number, and I am not going to invent a switching-cost figure I can't defend. The move is to price an unpriced risk with an honest range. What makes context residency a control question rather than a preference is the obligation underneath it: examiners, SOC 2, and the data-processing commitments we have made to 1,500+ financial institutions. When you have promised partners you can account for where their data lives, "it's inside a vendor's assistant and I can't get it out" is not an answer you want to give under questioning.

Turn "see / do / remember / check" into a vendor-evaluation control

There is a good four-question test making the rounds for the assistant already on your laptop: what can it see, what can it do, what does it remember, how do I check it. As personal hygiene it is sound. For a regulated buyer it lands one step too late. Those are not habits you form after adoption. They are due-diligence questions you answer before you sign, and each one has to become an enforceable contract right rather than a feature you hope exists.

So I rewrite the test as a five-verb scorecard, and it goes in the security questionnaire and the DPA:

• Export. Can I pull the full accumulated context out, in a usable format, on demand? Not through a support ticket. Not on a quarterly data-request SLA. On demand.
• Inspect. Can I see and scope what it remembers, with provenance — which facts were stated versus inferred, and who is allowed to see each one?
• Revoke. Can I cut its access to a channel, a repo, or a single memory in minutes, myself, without opening a case?
• Route. Can I point the same context at a different model or a different vendor, or is the memory welded to the brain?
• Audit. Does every remembered fact and every action it takes carry a source, an owner, a timestamp, and a label saying whether the system may act on it or a human interprets it first?

Run it before adoption, keyed to the data class the vendor will touch. A vendor that cannot answer "can we export our own context on demand" has handed you a finding, not a negotiating position. The regulators point the same way. CCPA's automated-decision-making rules take effect in January 2027. Treasury's Financial Services AI RMF, published this February, organizes its expectations around the full AI lifecycle. NIST's AI RMF runs as the spine under both. Every one of them assumes you can produce evidence about what an automated system knew and did. If you can't export and audit what a vendor's assistant remembers about you, you will find that out at the exam rather than at the signing.

The Lemonade email is a non-human-identity incident, not a memory bug

The failure mode, made concrete. In a widely circulated account, an OpenClaw personal agent autonomously sent a formal appeal email to Lemonade Insurance after reading its owner's silence as approval. Whether or not every detail is exact, the shape is right — and the shape is the point: the right outcome, reached by exactly the mechanism a regulated business can never allow. An agent crossed a "send" boundary by guessing at intent.

That is a failure class you already own — an over-permissioned service account taking an irreversible action without approval. The only genuinely new thing is the cost of a misread. A model that misread intent used to hand you a wrong sentence and a human caught it. Now it takes an action that leaves the building. It sends the email, files the ticket, moves the money.

This is the act-or-interpret boundary I keep coming back to. Every output carries a label: something the system may act on, or something a human must interpret first, and interpret routes to a person. Pair that with least-privilege scopes per agent and the blast radius is contained. Skip it and every assistant is one more ungoverned principal — and there are a lot of them. Non-human identities already swamp the human ones in any modern environment, and the Cloud Security Alliance keeps warning that every new agent widens a gap that is already lopsided by orders of magnitude.

Enforcement is two controls. An approval gate on any action that mutates state or leaves the tenant. And a mandatory receipt on every action, carrying source, owner, status, the blocker if it stopped, and the act-or-interpret label. That receipt is the control record — the log an examiner asks for and the change history the board expects — produced as a byproduct of how the system runs rather than written up afterward. Both the gate and the receipt have to live in the memory layer. Custody of the context is a control decision, not a storage one.

Portable context is a FinOps and re-certification lever

There is a cost angle too, and it isn't the one you would guess. Serious teams already switch between Claude, GPT, Kimi, and Codex depending on the task. If your memory lives inside one of those tools, you become the migration layer every time you switch. For a regulated company that migration is not only moving data. It is re-earning every certification and control assertion that touched the old system. You pay the migration bill and the re-certification bill together, every time the model underneath you changes. This is not per-request token FinOps; that is a different post. This is the amortized cost of lock-in, and it comes due on a schedule you do not control.

Flip it. One context store you own turns a model change from a data migration plus a fresh audit into a routing change. The same gateway discipline I would put in front of a swappable model belongs in front of the context, except here the context is the durable, hard-to-move thing and the model is the cheap part you rent.

Here is the part that inverts what I argued when we built AgentOS. You do not have to build a platform to get this. That post made the case for building the harness; this one makes the case for building nothing. The move is procurement and governance: make context portability a contract requirement, keep the store under your own DPA, and get the export, inspect, revoke, route, and audit answers in writing before you sign. Owning the context store is the cheap version of owning the harness, and most companies should do the cheap version first.

Put context custody on the risk register, Monday

Four moves, none of which requires a research budget. Add a line to the risk register — "context custody / AI vendor concentration" — with a named owner and a data-residency classification for every context store you can find. Run the five-verb scorecard against every AI vendor already sitting in your files, your Slack, and your repos, and treat "no export on demand" as a finding rather than a footnote. Require approval gates and mandatory receipts on any agent that can act. And make context portability a DPA clause before the next renewal, while you still hold the pen.

Then bring it to the board as a decision with an explicit ask and a management recommendation, not as a status update. The institutions that cannot frame and answer these questions will have their AI strategy, and their control posture, dictated to them by whoever holds their context. You can price that now, on your terms, or discover the number later, on theirs.

One question I would genuinely like answered: has anyone actually gotten a full context export out of a vendor on demand, or is that still a clause everyone signs and nobody tests?

That is Anthropic's CORE benchmark, published earlier this year and presented at the AI Engineer Summit, and it should be required reading for anyone deploying AI inside a bank, a fintech, or anywhere an examiner will eventually knock. If you only read model headlines, the number makes no sense. The model didn't change. Everything around the model did. And "everything around the model" turns out to be the part that decides whether you have a product or a science experiment.

Anthropic has a clean way of naming the two halves, and I've adopted it wholesale. The model is the brain. Everything else is the harness: where the agent runs, what it's allowed to touch, what it remembers between sessions, how it manages its own context, how it checks its work, and what happens when it fails. The brain gets the magazine covers. The harness decides whether the brain is useful or dangerous.

At SavvyMoney we made a decision that surprises people when I describe it. We built our own harness, and our own brain layer, rather than buying a finished agent off the shelf. We call it AgentOS.

It started as a memory problem. Every engineer on the team was using an AI coding agent, and every instance started from zero: no awareness of our conventions, our past decisions, the errors we'd already debugged, or what anyone else was working on. Brilliant, and amnesiac. AgentOS began as the shared brain that fixes that, a persistent, searchable, team-wide knowledge layer that every engineer's agent connects to, so one person's hard-won lesson becomes everyone's context and a session can be handed off with its full history intact. That alone changed how fast the team moves.

But the moment you give a fleet of agents a shared brain and the ability to take action, you've built something that, in a regulated company, you are absolutely going to have to answer for. That's where my other hat comes on.

In a regulated company, the harness is the governance

Every AI governance framework asks for the same things. NIST AI RMF, ISO 42001, the EU AI Act, the newer state automated-decision rules: know what your system can do, control what it can act on, prove a human is in the loop where it matters, keep evidence that's current rather than annual. Every one of those requirements is a property of the harness, not the model.

You cannot buy a model that is "compliant." Compliance isn't a property a brain has. It's a property of the scaffolding you wrap around the brain: the permissions, the audit trail, the boundary between an output the system may act on and one a human must interpret first. The harness is not an optimization layer that makes the agent a little faster; it is the control, and it is the thing the examiner is actually auditing.

That turned build-versus-buy into a question I already knew the answer to. Would I outsource my control environment to a vendor whose roadmap I don't own and whose philosophy I can't see? In a company that has to prove its security to 1,500+ financial institutions and their regulators, no. You don't rent your controls.

Most of a real agent isn't the model

Anthropic's own engineers keep repeating that the model call is a small fraction of a production agent. The rest is plumbing, the unglamorous infrastructure nobody demos: session state that survives a crash, a permission pipeline that classifies every action before it runs, a token budget checked before the expensive call rather than after, a verification step that confirms the agent actually did what it claimed, an event log that records what the system did and not just what it said.

That list is also, almost word for word, a control catalog. So when I scoped the work, I told the team to ignore the model for the first month and build the plumbing. That's where both the reliability and the auditability live. The principles we organized around, in priority order:

• Scoped tool authority. Every agent gets the narrowest set of capabilities a task requires, gated by per-user access controls that default to deny on anything unknown, with an approval step for actions that mutate state or can't be undone. Least privilege isn't a nicety here; it's the difference between an agent that can read a repository and one that can change production.
• An audit trail as a first-class object. Every tool the system invoked, every permission granted or denied, every output it produced is structured, logged, and replayable. If you can't reconstruct what happened, you can't defend it, and you certainly can't put it in front of an auditor.
• The act-or-interpret boundary. I've argued before that this single design decision is the real AI control. Every output is labeled: something the system may act on, or something a human interprets first. The harness enforces the label. That's what turns "human oversight" from theater into a control with teeth.
• Durable state and verification. Work is modeled as explicit, recoverable steps rather than a chat transcript, so a crash mid-task doesn't double-fire a side effect. And the agent has to prove a result before it's trusted.
• Memory with provenance. The system remembers, but every memory carries where it came from, whether it was stated or inferred, and a visibility scope. Memory without provenance is accumulated hallucination, and an unmanaged retrieval layer is a fresh injection surface.
• One governed path for every model call. Every request to the brain runs through a single dispatcher, so the same audit log, the same content scrubbing, and the same refusal rules apply uniformly. No code path gets to route around them.

None of that is exotic. It's the same discipline that has always separated software that ships from software that demos: version control, least privilege, observability, rollback. The models are new. The engineering that makes them safe at scale is not.

Why we own the brain, too

The "brain" half of the decision is subtler. We did not build a foundation model; that would be malpractice for a company our size. We treat the model as what it is becoming, a commodity component. Benchmarks turn over every quarter, and the best model this month is rarely the best model next month. So the harness holds the model at arm's length, behind an interface, swappable. We don't build our identity on one vendor's weights.

What we do own is the intelligence that's actually ours: the institutional knowledge, the memory, the context that makes the system understand our environment instead of the internet's average opinion of it. That layer doesn't get rented back to us by whichever app wins this month. It stays in our control, portable across whatever brain we point it at. Own the harness, own the knowledge, rent the raw reasoning. That's the posture.

Why a combination of harnesses, not one

The question I get next is always the same: which harness? Wrong question. We don't bet AgentOS on a single agent framework any more than we bet it on a single model.

Agent products differ along a few axes that matter: where they run (local, cloud, or hybrid), who picks the model, what the interface contract is. Most of them die stuck in the middle. Adopt one framework wholesale and you inherit its single set of blind spots, and you concede your position on the things that are actually defensible: workflow depth, memory, and verification.

So we treat the agent ecosystem as a menu of patterns rather than a vendor decision. Our durable core stays untouched: a shared, searchable team-memory substrate, deep enterprise integrations, one governed model layer, compliance gating. Into that we graft the specific ideas that close real gaps. We borrow patterns; we refuse wholesale replacement. What each reference point contributes:

• OpenClaw. The local-first archetype: agents that run on your own hardware and actually take action in the real environment. That action-taking is exactly why local agents win adoption, and exactly why they punch holes through security boundaries. We want the upside — agents that do real work and improve themselves — without the ungoverned downside, so we reproduce the capability behind managed, gated, audited equivalents.
• Hermes. The most fully realized personal-agent harness in the open landscape, but a single-user shape. We're a shared team brain, so we don't replace anything; we graft on the few patterns that make agents stickier for an individual: automatic skill mining, a self-sharpening model of the user, frictionless in-conversation memory capture.
• OpenBrain. A portable second brain exposed over a standard tool protocol, so every tool you use reads and writes the same store. It validates our foundational thesis: own the substrate, expose it over an open protocol, keep one shared memory instead of many siloed per-vendor ones. The invariant we hold is strict. Human and agent read and write the same source of truth, with no sync layer, because a sync step means it's really a copy, and copies drift.
• The swarm pattern. From other open projects we pull isolation and inter-agent messaging, plus budget and coordination governance, into our own multi-agent coding harness: worker agents run in isolated worktrees, detect when they'd touch the same files, and operate under hard budget caps with pause-and-approve at the limit.

The composition shows up all the way down at dispatch. Hard, isolated tasks route to an autonomy-plus-correctness-gate shape; cross-tool coordination routes to an integrated, human-in-the-loop shape. We pick per task by the shape of the work, not by a leaderboard. That's the whole thesis, operationalized: don't bet on one.

Running on AWS Bedrock and AgentCore

The brain is interchangeable. The egress is not. Every model call in AgentOS goes through AWS Bedrock. We never call model vendors directly, and a thin internal facade exposes one client so application code never imports a vendor SDK.

The reason is governance, not preference. One cloud provider is one trust boundary and one egress path, which is dramatically easier to audit than several SaaS destinations under separate contracts, logging pipelines, and data-processing agreements. It inherits our existing cloud controls for free: network isolation, audit logging, encryption at rest, threat monitoring. And it keeps regulated data from fanning out to a dozen external APIs.

Inside that boundary we route across tiers — fast and cheap, a balanced default, deep reasoning, and a bulk tier — chosen per request by complexity, with prompt caching wired into the hot paths so we aren't paying repeatedly to resend large, stable tool and schema context every turn. Resilience stays inside the cloud too: we fail over across regions, not across vendors. Cross-vendor fallback would reintroduce the exact sprawl and data-boundary problems the single egress was built to eliminate.

For the capabilities that gave me the most pause, we lean on Bedrock AgentCore's managed runtimes instead of running them ourselves:

• Managed browser. Agent-driven web automation runs in a managed sandbox, not in our service. A standing privilege-escalation and CVE risk belongs on the provider's side of the boundary.
• Managed code interpreter. Executing model-generated code is the highest-risk thing an agent can do, so we delegate the sandbox lifecycle and keep that blast radius off our infrastructure. Conservative by default.
• Per-session runtime. Short, bounded, human-initiated coding tasks move onto managed per-session runtimes; long-running and fully autonomous jobs stay on our own container runtime, and routing fails closed to the self-hosted path. The managed path ships behind a kill-switch and a scoped canary until completion, cost accounting, and lifecycle are proven.
• Workload identity. Managed runtimes authenticate with short-lived, minted credentials instead of standing long-lived secrets: least privilege by construction, smaller blast radius.

Worth saying what we deliberately did not adopt. We don't use a cross-agent federation gateway for internal agent-to-agent delegation, and we don't outsource our core memory to a managed primitive. Coordination stays in-process. Memory is our own pipeline, because it's the differentiator I'm least willing to rent. Adopt the managed pieces that clearly reduce risk or toil; skip the ones that don't.

The five layers of guardrails

Letting agents act in a regulated environment is acceptable only because no single control is load-bearing. The danger the local-agent world proved is action-taking power plus broad data access. So we stack independent layers, and a gap in one is backstopped by another. Defense in depth, applied to agents.

• Content safety. A managed, continuously-updated filter screens text in and out for harmful content and prompt-injection attempts, with optional anonymization of sensitive personal data, returning a clear allow / block / anonymize verdict with reasons. It's one band in the stack, not the perimeter, and far better than hand-written "don't say X" instructions sprinkled across every prompt.
• Formal facts checking. Automated Reasoning evaluates the model's factual claims against a curated policy of verified organizational facts and returns an auditable verdict per claim, naming which premise was satisfied or contradicted, rather than an opaque confidence score. For regulated communications, compliance can read the policy and trace exactly why a claim was flagged, and improving coverage is a policy task rather than a code change.
• Output schema validation. Every tool result passes through one central middleware before it reaches the model: validate against the tool's declared contract, drop undeclared fields, truncate oversized payloads, log every modification. With a large catalog of tools written by many people, that stops schema drift and untyped-blob smuggling, and turns an advisory convention into a guarantee every new tool inherits for free.
• The lethal-trifecta gate. A runtime gate watches for the combination most exploitable via prompt injection: access to private data, exposure to untrusted content, and the ability to cause side effects, all in one run. Any two are fine. All three at once is exactly the thing you build a control to catch. Each tool declares which of the three it touches. The gate doesn't blanket-block, because some legitimate workflows need all three; it escalates to per-run authorization, and it's introspectable so a human can see why a sequence was flagged. That scales where per-tool review can't, and it catches the subtle path where untrusted content is stored, read back later, then acted on.
• Central dispatcher discipline. Because every model call goes through one dispatcher, three protections apply uniformly and can't be bypassed: a universal scrubber strips secrets and sensitive personal data, a regulated-data refusal instruction leads every call, and every invocation is fully audited. No individual code path can forget to scrub, skip the refusal posture, or miss logging. The control is structural, not dependent on each author remembering it.

This is a precondition, not an afterthought. Agents that browse, run code, and act are acceptable only because these five layers sit underneath them. The harness is the governance; the guardrails are how the governance holds.

How I framed it for the board

The hardest part was getting everyone to stop treating this as a tool purchase. A team that adopts an agent platform doesn't just buy a subscription. It starts building habits, processes, and verification steps around one vendor's idea of how work should happen. Six months in, that's not a tool you can swap; it's an architecture you're married to. I've watched this movie before. It was called the cloud, and the companies that treated it as a commodity spent the next decade paying migration costs.

So I framed the decision the way I'd frame any infrastructure commitment. Not "which agent is cheapest," but "which architecture matches how we have to operate, and what does it cost us to change our mind in eighteen months?" For a regulated business, that pointed straight at owning the layer where the controls live. We built incrementally, because you can't start with the finished system; it has to accumulate. Unglamorous plumbing first, then capability compounding on top of a control plane we trusted.

The payoff isn't only safety. It's provable maturity. When a partner or an examiner asks how our automated systems make decisions, we don't hand them a vendor's marketing page. We walk them through our own harness: the permissions, the boundary, the audit trail. The conversation that usually slows a deal down becomes the part where we look more serious than the alternative.

The bet

The industry is converging on a quiet consensus: the model becomes the commodity, and the harness becomes the product. In every regulated domain — finance, health, anything with an auditor — I'd put it more sharply. The harness becomes the governance. The brain is rented reasoning; the harness is the part you have to own, because it's the part you have to answer for.

That's why we built our own. If the decision were in front of me again tomorrow, I'd make the same call — only sooner.

Most AI compliance work is theater performed after the system already shipped. Someone exports a few chat transcripts, writes a policy PDF, and calls it governance. Then an examiner asks a question the logs cannot answer, and the whole thing falls apart in one meeting. That is the pattern I keep watching teams repeat as they put AI into regulated workflows.

The fix is not more policy. It is treating audit evidence as a non-functional requirement you build in from the first commit, the same way you build in latency budgets and error handling. If you cannot reconstruct what the model saw, what it produced, who approved it, and why it was allowed to act, you do not have a compliance gap. You have an engineering gap that happens to show up at audit time.

Map controls to a framework before you write a line of orchestration code

Pick your control framework first, then design backward from it. For most of us in regulated environments that means the NIST AI RMF as the spine, plus whatever overlays your sector demands. The US Treasury published a Financial Services AI RMF in February with 230 control objectives across seven domains, and Texas TRAIGA, in force since January, gives you a safe harbor specifically for adopting the NIST AI RMF. Frameworks are converging on it for a reason. It maps cleanly to engineering artifacts.

The trick is to refuse the abstract version. "Maintain human oversight" is not a control you can test. Translate each objective into a thing that exists in your system: a log line, a database row, an approval record, a config flag. When a framework function says you should be able to trace an output back to its inputs, that becomes a concrete requirement that every inference call writes a provenance record. Now the auditor is reading your telemetry, not your prose. Do this mapping in a spreadsheet that lives next to the code, with one column for the control and one column for the exact evidence artifact that satisfies it. If a control has no artifact, you have found a real hole.

Capture provenance and decision logs as first-class data

The minimum viable provenance record for any AI-touched decision is boring, and that is the point. For every call, log the model id pinned to an exact version, the full resolved prompt including retrieved context, the raw output, the human or system that triggered it, the timestamp, and the downstream action it authorized. Hash the inputs so you can prove the record was not edited after the fact.

Pin the model. This matters more than people think. When GPT-5.5 Instant became the ChatGPT default in May, it was exposed as a floating "chat-latest" alias. Floating aliases are a model-pinning risk: your behavior changes underneath you and your audit trail says nothing changed. The same logic applies to Claude Opus 4.8, which shipped in late May with a stable API id of claude-opus-4-8 precisely so you can pin it. Log the stable id, not the friendly name. And remember that any model can be pulled out from under you. Fable 5 and Mythos 5 launched on June 9 and were suspended three days later under a US export-control directive. If your pipeline assumes a model is permanently available, you have a continuity gap and an evidence gap at the same time.

Provenance also has to cover the cost and routing decisions, because examiners increasingly ask about them. I run what I call minimum effective intelligence routing: send each task to the cheapest model that still yields an accepted result, with per-request cost attribution and budget caps. That is good FinOps, and it is also evidence. Bedrock added request-level usage attribution in May and Microsoft Foundry shipped project-level cost attribution at the end of May, so the platforms are finally giving you the hooks to log this natively. Use them.

Build a trust layer so pretty-but-wrong output never ships

This is the part teams skip and the part that bites hardest. Generative models produce confident, well-formatted output that is wrong in ways that survive a casual read. A clean table of numbers that does not foot. A summary that inverts a material clause. The formatting is the problem, because it buys credibility the content has not earned.

So I put a trust layer between generation and anything a human or a system will rely on. Two mechanisms, both cheap. First, a checks tab. For any numerical or structured output, run deterministic validations the model does not get to skip: row counts, totals that must reconcile, ranges that must hold, referential checks against a source of truth. These are assertions, not suggestions. If a total does not match, the output is blocked, not flagged.

Second, a hostile-reviewer pass. Take the generated artifact and run a separate prompt whose only job is to attack it: find the unsupported claim, the number with no source, the clause that contradicts the input. Crucially, the reviewer runs as an independent call with its own context, ideally a different model, so it is not just the original model agreeing with itself. The output of the hostile pass is itself logged as evidence that the check happened. Neither mechanism is exotic. They are the AI equivalent of unit tests and code review.

Validate AI-touched data migrations like the high-risk operations they are

Letting an AI agent move or transform production data is where I have seen the scariest near-misses. The loosely reported anecdote that an AI coding agent deleted a startup's production database and its volume-level backups in roughly nine seconds is funny until it is your data. Speed is exactly the danger. An agent can do irreversible damage faster than a human can react.

So data never leaves staging on the model's say-so. The pipeline I insist on has four gates. Canary records first: seed known inputs with known correct outputs and confirm the migration handles them before touching real data. A rejected-record log: anything that fails validation goes to a quarantine table with the reason, and a non-empty quarantine blocks promotion until a human reviews it. Row-count reconciliation: source count, transformed count, and loaded count must agree, and any drift halts the run. And a human approval gate before data leaves staging, with the approver's identity written to the same provenance log.

The unifying rule underneath all of it: never let the model self-certify production data. The model can propose. It can draft. It can flag. It does not get to be the final authority that says its own output is correct and release it. The moment the generator is also the validator, your evidence is worthless, because the control and the thing it controls are the same component.

Why this satisfies the examiner without you trying

Notice what we did not do. We did not write a governance manifesto. We built logging, assertions, an independent review pass, and a gated migration with human sign-off. Every one of those is an engineering practice a good team would want anyway. They just happen to produce exactly the artifacts a HIPAA, SOC 2, or SOX examiner asks for: traceability, segregation of duties, evidence of review, and proof that a human authorized material changes.

That is the whole move. Stop building compliance as a layer you bolt on for the audit, and start building systems whose normal operation emits audit evidence as exhaust. When the examiner shows up, you are not scrambling to reconstruct a story. You are handing them a query.

That is the shape of most enterprise AI programs right now. Forty pilots, or sixty, or a dozen; the number is a distraction. Every one has a sponsor, a slide, and a screenshot of the day it worked. None has a graduation gate, a kill date, or a number that says how it ranks against the thirty-nine others competing for the same engineers, data-access decisions, and scarce reviewer attention. That is not a portfolio. It is a science fair with a cloud bill.

A venture investor runs the opposite thing. A VC runs a book: a ranked set of bets, each sized to its expected value, most expected to return nothing, a few funded hard because the math says so, and the losers cut early so the capital flows back to the winners. The enterprise AI program that survives the next two years is the one that stops running a science fair and starts running a book.

Let me be precise about where I stand, because this is a chief-information-officer's problem and I am not sitting in that chair yet. I run security and DevOps for a fintech that has to prove its controls to more than 1,500 financial institutions and their examiners, and we built AgentOS, a governed internal agent platform with real users. That platform is where the demand side lands on my desk: every week, new use cases queue up asking to be pushed to production. I do not own the enterprise IT P&L. I do own the gate that decides which agent use cases graduate, so I have thought hard about ranking a portfolio you cannot afford to run whole. This is that method.

A portfolio is ranked. A science fair is just alive.

The disease is not that companies run too many pilots. It is that they refuse to rank the ones they run. Ranking forces a comparison, a comparison forces a judgment, and a judgment means telling a sponsor their thing lost. So the ranking never happens, and forty pilots sit in pilot purgatory: permanently mid-stage, never scaled, never stopped, quietly consuming the two resources that actually constrain an AI program.

Those resources are not tokens. A widely cited MIT report on the state of AI in business last year found that the large majority of enterprise generative-AI pilots produced no measurable P&L impact; the figure quoted everywhere was around 95 percent. The lesson is not that most pilots fail. Most bets in any real portfolio do not pan out, and that is fine when winners are funded and losers cut. The failure is running all of them at once, forever, as if that were free.

It is not free, and the cost is not the cloud bill. The scarce resource is attention: senior engineering time, data-access decisions, the few people who can review a model's output without rubber-stamping it. Forty unranked pilots spread that too thin to make any single bet succeed. Five ranked ones concentrate it, and concentration is what turns a promising pilot into production.

Score every use case, not the person who pitched it

The antidote is a rubric applied to every use case before it competes for a dollar of engineering time: the same three axes for the executive's pet idea and the intern's side project. This is how a disciplined investor reads a book. You do not fund the best pitch. You fund the best risk-adjusted expected value, and you make yourself write the number down.

• Expected value, not headline value. The probability the use case actually works in production, times the annual value if it does. A one-in-five shot at a big number and a near-certain shot at a small one can score the same, and both beat a beautiful demo with no path to a real workflow. Forcing the probability term onto the page kills "this could be huge," because "could" is where the whole disagreement lives.
• Feasibility, measured where projects actually die. Not "can the model do it," because models can do a startling amount. Is the data reachable and clean enough. Does it integrate with a system someone owns. Will the humans whose workflow it changes actually adopt it. Most pilots die on feasibility, not capability, and feasibility is the axis a good demo is built to hide.
• Risk, priced as reversibility. What data class it touches, what its output may act on, and how hard it is to unwind. In a regulated shop, a use case that touches regulated customer data and acts autonomously carries a risk weight that can sink an otherwise strong expected value, and it should. Risk is the discount rate on the whole thing.

The output is not a precise number. Anyone who says their pilot-scoring model is precise is selling something. It is a defensible ordering. When two use cases land a row apart, argue which is higher; that argument is cheap and useful. When one sits twenty rows above another, the conversation is over, and no one's charisma decided it.

Fund stages, not projects

The second discipline a VC has that most AI programs lack: they do not write the whole check up front. They fund a stage, watch what it returns, and decide whether the next one earns a bigger check. A pilot is not a promise to scale. It is money spent to buy information about whether scaling is worth it: an option, not a commitment. Treat every pilot as bought information and the weight of "killing" it drops away, because you already got what you paid for: an answer.

The mechanism is old and boring and it works. Robert Cooper's stage-gate model, a product-development framework older than any of this, puts a decision gate between stages, where a use case graduates, iterates, or dies. Adapted to an AI portfolio, it is four stages and three gates:

1. Idea. Scored on the rubric, ranked against the book, cheap to enter and cheap to reject. Most ideas should stop here, and that is the stage working, not failing.
2. Funded pilot. A small, time-boxed check to answer one question: does this clear its feasibility and risk on real data. The graduation criterion is written before the work starts, a specific measurable result, not "it looked promising."
3. Limited production. Real users, real data, real controls, a bounded blast radius. The gate is adoption and reliability under real load, and this is where the governance and control-plane work finally earns its keep. The third gate, not the first. You do not build the full control stack for a use case that has not earned one.
4. Scaled. The winner. The one you concentrate the freed-up attention on. A real portfolio has few of these, and that is the point.

The checks get bigger as the evidence accumulates, never before. The most expensive mistake in enterprise AI is writing a production-sized check at the idea stage because a demo was compelling: money poured into a use case that has not survived a single gate.

Kill criteria are a feature, not a failure

Here is the line that separates a portfolio from a science fair, and it is written at funding, not at the funeral. Every pilot gets a kill condition and a kill date the day it is funded, before anyone's identity is wrapped up in it. If by that date it has not cleared a specific bar, it stops, and that is not a mark against anyone. While the sponsor is still unattached is the only time you can write that honestly, because once three months of effort have gone in, the sunk-cost reflex makes every flat line look about to turn up.

A healthy portfolio has a kill rate, and a meaningful one. If nothing in your AI program has been stopped this quarter, you are not running a disciplined book. You are hoarding, and the tell is that your oldest pilots are your least defensible. Gartner's TIME model (tolerate, invest, migrate, eliminate) exists precisely because application portfolios rot when nobody is allowed to say "eliminate," and an AI portfolio rots the same way, faster. Killing a pilot is not a loss. It returns capital to the pool: the engineers and the reviewer attention that can now go to a bet with a real chance. A VC does not mourn the write-off. It was priced in from the first check.

Two adjacent arguments get conflated with this one constantly. Governing a single agent well and metering a single experiment honestly are real problems. But they sit downstream. Whether a specific use case has earned a governed agent, a metered budget, or a slot on the reviewer's calendar at all is the portfolio question, upstream of every per-agent control. You can run an immaculate control plane and still be running a science fair, if the thing it governs is forty bets nobody ranked.

The portfolio is an operating model, not a spreadsheet

A scoring exercise you run once and file is a science fair with a spreadsheet stapled to it. The portfolio is an operating model: an owner, a cadence, and a cost you can actually see.

The owner is a single accountable person who runs the book, the intake gate every new use case passes through and the one who convenes the rebalance. The cadence is quarterly at minimum: re-score the live pilots against the new ideas, re-rank, graduate what cleared a gate, kill what hit its kill date, and move the freed attention to the top. And the cost has to be legible. Technology Business Management and the FinOps practices around it exist to attach a real, defensible number to each line, so expected value is weighed against what a pilot actually consumes, not what its sponsor wishes it cost. A portfolio you cannot cost is a portfolio you cannot rank, because half the ranking is the denominator.

This is also the version of an AI program a board can actually govern. Forty green demo screenshots let a board decide nothing. The book — the ranked bets, the graduation rate, the kill rate, the concentration of spend behind the top few — lets it do its job: ask whether the allocation matches the strategy. I report to boards today, and the gap between those two artifacts is the gap between a meeting that produces a decision and one that produces a nod. Give the board the book.

Run the book, not the science fair

Score every use case before it competes for an engineer, and rank the book out loud. Fund in stages, keeping the checks small until the evidence is big. Write the kill condition the day you fund, not the day you admit it is dead. Put one owner on the book and rebalance quarterly. None of that requires a tool you do not already have.

So I will ask you the question I ask myself every time a new use case shows up at the platform gate: what is the last AI pilot your organization actually killed, and did you write its kill condition the day you funded it, or the day you finally admitted it was dead?

Most of the AI regulation coverage I read is written for lawyers, and most of it is wrong about timing. The headline this spring was that the EU pushed its scariest AI rules out to 2027. True, and also a trap. If you are an engineering leader who read "deferred" and exhaled, you misread the calendar. The part that can fine you a percentage of global revenue did not move. It activates this August.

So here is the map I keep on one page: four things with teeth, when they bite, and what your team should build instead of what your policy deck should say. I write this as a practitioner who has run cloud security and platform teams in regulated environments, not as anyone's compliance department.

The EU AI Act did not get easier, it got more specific

The "Digital Omnibus" package, published on 7 May, deferred the high-risk obligations under Annex III to December 2027. That is the long list: conformity assessments, risk management systems, the heavy documentation for systems that touch credit, employment, and the like. Real relief, real engineering time bought back.

But the obligations for general-purpose AI models, the GPAI tier, were not deferred. The Commission's enforcement powers there switch on 2 August 2026, with fines up to 3 percent of global annual turnover. If you fine-tune, host, or build on a foundation model and you put it on the EU market, you inherit GPAI obligations, and the enforcer has standing in August whether or not your specific use case is "high-risk."

The practical move is unglamorous and you can start it Monday. For every model you use, including the ones reached through a cloud provider, collect and store the provider's documentation: the model card, the training-data summary, the acceptable-use and copyright posture, the published evaluations. The Act expects it to flow downstream, and most teams discover they cannot produce it for half their models. That gap is the work.

The documentation discipline is not bureaucratic theater, because models move under you. GPT-5.5 Instant became the ChatGPT default on 5 May and is exposed as a floating "chat-latest" alias, which means the thing answering your users can change without a version bump on your side. In the other direction, Fable 5 and Mythos 5 launched on 9 June and were pulled offline three days later under a US export-control directive, the first time a major US lab's flagship went dark within days of release. If your compliance evidence points at "the model" as an abstraction, both of those events break your audit trail. Pin model IDs. Treat a pinned ID, like the stable "claude-opus-4-8" identifier, as a compliance artifact and not a convenience.

The US has no AI Act, which is exactly why the sector rules matter more

People keep waiting for a federal framework and treating the absence of one as the absence of rules. In financial services that reading is dangerous, because the binding guidance is already here, just sector-shaped.

On 19 February, US Treasury published a Financial Services AI Risk Management Framework with 230 control objectives across seven domains. Two hundred and thirty. That is a control catalog, not a position paper, and control catalogs are how examiners think. You do not have to be a bank for this to matter. Sell into one and their third-party risk process will hand you a subset of those 230 and ask you to evidence them, and "we take AI safety seriously" is not an answer to a control objective.

NIST AI RMF is the lingua franca, so adopt it as your internal source of truth

Here is the contrarian part: stop treating each regulation as its own project. The EU's GPAI documentation, Treasury's 230 controls, and the state laws below all describe the same underlying functions in different dialects. NIST AI RMF gives you the dialect they all translate into. Govern, Map, Measure, Manage. Organize your evidence by those functions once, and you answer most questionnaires by reindexing rather than by re-doing.

Texas makes this concrete. TRAIGA, the Texas Responsible AI Governance Act, has been in force since 1 January, and it includes something most laws do not: a safe harbor for organizations that follow a recognized framework, with NIST AI RMF named explicitly. Read that for what it is: a regulator telling you the framework costs less than the incident, and offering a discount for adopting it early. Take the discount.

The fourth corner is security-specific. On 16 December NIST published a preliminary Cyber AI Profile, IR 8596, which maps AI systems onto the cybersecurity controls your security team already runs. This is the bridge that keeps "AI governance" from spawning as a parallel org that never talks to your SOC. The threats it anticipates are not hypothetical. OWASP mapped prompt injection to 6 of its 10 agentic-AI Top 10 categories on 11 June. SearchLeak, CVE-2026-42824, was disclosed on 15 June as a one-click data-exfiltration flaw in Microsoft 365 Copilot, the second exfiltration class of its kind after EchoLeak. Your AI risk register and your vulnerability management need to be the same register.

The one thing to build: an evidence pipeline, not a binder

If I could make every engineering leader do one thing this quarter, it would be this. Compliance fails at audit time because the proof was not captured when the control ran. The controls are usually there. The evidence is not. So capture it at runtime.

A workable evidence pipeline has four parts, and none of them is a document.

1. An inventory that updates itself. Every model, agent, and dataset, with its pinned version, its provider documentation link, and its owner. Maintained by hand, it is already stale.
2. Request-level attribution. Log which model version served which request, at what cost, under which budget. Amazon Bedrock added request-level usage attribution on 20 May, and Microsoft's renamed Foundry shipped project-level cost attribution on 31 May. The same per-request record that proves your FinOps story proves your provenance story.
3. Automated control checks. Wire continuous checks to the NIST AI RMF functions, emitting pass or fail evidence the way your cloud posture checks already do, each one mapped to the relevant Treasury control and EU obligation once, in metadata.
4. Retention and tamper-evidence on all of it. The point is to answer a question asked twelve months from now about a model that no longer exists.

Build that and the four regulations on this page stop being four programs. They become four views of one dataset. Two dates for your calendar before you close the tab. 2 August 2026, when EU GPAI enforcement and its 3 percent fines go live. December 2027, when the high-risk obligations you just got a reprieve on come due, which is sooner than it sounds once you price the engineering.

I am curious where others draw the line between governing the model and governing the application around it, because most of the real risk I see lives in the application. Tell me how you are splitting it.

If your application had one of those model IDs hard-wired into a request loop, your June 12 was spent writing an incident report instead of shipping. The lesson is not "pick a different lab." The lesson is that single-provider inference is now a continuity risk on the same tier as a single-AZ database or a single-region control plane. Your inference provider is a dependency you do not control, and most architecture diagrams still draw it as a utility that never goes down. We learned that lesson the hard way with regions years ago. We are about to relearn it with models.

I run cloud security and platform teams in regulated environments, so what follows is the actual mechanism of making inference survivable on AWS. Not slideware. Things you can put in a backlog Monday.

Treat the model as a swappable backend, not a hard dependency

The first failure mode is application code that talks directly to a vendor SDK with a model string baked in. That couples your business logic to one company's roadmap, one company's pricing, and, as of this month, one government's export posture.

Put a gateway in front of it. Concretely, your services call an internal inference endpoint that speaks one stable contract. Behind that endpoint, you route to Amazon Bedrock as a primary and to a second provider as an independent fallback. Bedrock hosts multiple model families under one API surface, and as of late April it added OpenAI frontier models, Codex, and managed agents in preview. That is useful, but do not let "multi-model inside one vendor" convince you that you have redundancy. A single export directive or a single account-level issue can take the whole surface with it. Real redundancy means a second control plane you can fail over to, owned by a different company.

The gateway pattern buys you four things at once. A place to enforce request-level authorization. A place to attribute cost. A place to pin versions. A place to reroute when a backend disappears. You are not building this to be clever. You are building it so that swapping a model is a config change and not a code deploy under pressure.

Pin your versions, then schedule the re-validation

The opposite mistake is just as dangerous as hard-coupling. GPT-5.5 Instant became the ChatGPT default in early May and is exposed through a floating "chat-latest" alias. Floating aliases are wonderful for a chat window and a quiet catastrophe for a regulated workload. The model under that alias can change without notice, which means your evaluation results, your safety testing, and your output formatting were all validated against something that no longer exists.

Pin to explicit, immutable model IDs. Use "claude-opus-4-8", not "latest." Opus 4.8 shipped on May 28, roughly 41 days after 4.7. That cadence is the point. Frontier models now move on something close to a six-week rhythm, so your pinned version will drift from the frontier quickly.

Pinning is only half the control. The other half is a re-validation cadence. Put a standing item on the calendar, every quarter at minimum, to run the new candidate model against your evaluation set, your prompt-injection tests, and your cost profile before you promote it. Pinning without re-validation is how you wake up two years behind on capability and price. Re-validation without pinning is how you ship untested behavior. You need both, and you need the schedule written down where an auditor can see it.

Repatriate the inference that legally cannot leave

Some data cannot go to a third-party API at all. Not "should not." Cannot. If you operate under HIPAA, under SOC 2 commitments you actually made to customers, or under the kind of financial-services controls the US Treasury laid out in February with 230 control objectives across seven domains, then for certain data classes the right architecture keeps the model inside your perimeter.

This is now realistic. Gemma 4 open-weight models released on May 1, which gives you a self-hosting path for the data that cannot leave. The pattern on AWS is straightforward. Run the open-weight model on inference instances inside a controlled VPC. No internet egress. Private subnets. Endpoint policies that deny anything you did not explicitly allow. The same data-loss controls you would put around a production database. The model weights live in your account. The prompts and completions never cross a vendor boundary.

You will not run your whole workload this way. Open weights at a given size will not match a frontier model on the hardest tasks. That is fine. This is a routing decision, not a religion. Regulated, perimeter-bound data goes to the in-VPC open-weight model. Everything else can go to the gateway and out to Bedrock or a second provider. Draw that line explicitly in your data classification, because the moment the line is implicit, someone will send protected data to a public endpoint and call it a feature.

Route to the cheapest model that still passes

Continuity and cost are the same architecture problem viewed from two angles, and the gateway is where both get solved. Once you have an abstraction layer, you can do minimum effective intelligence routing. Send each task to the cheapest model that still yields an accepted result, and escalate to the expensive model only when the cheap one fails your acceptance check.

That requires measurement. Bedrock added request-level usage attribution on May 20, which means you can finally tie spend to a tenant, a feature, or a team instead of getting one undifferentiated bill. Wire that into per-request cost attribution and hard budget caps at the gateway. The FinOps Foundation named AI cost management the top wanted skill for 2026, with about 98 percent of organizations now managing AI spend, and the reason is simple. Without attribution you cannot route on cost, and without caps a runaway agent loop can spend a quarter's budget over a weekend.

The continuity dividend is that the same routing table that picks the cheapest passing model is the table you flip when a provider goes offline. You already built the muscle. Failover is just routing with a different trigger.

What to actually do Monday

Start with one honest inventory. List every production path that calls a model, and for each one write down the exact model ID, whether it is pinned or floating, what happens if that endpoint returns errors for an hour, and what data class flows through it. Most teams cannot answer the fourth column, and that gap is the real finding.

Then sequence the work. Stand up the gateway with one primary and one fallback. Replace every floating alias with a pinned ID and put the re-validation date on the calendar. Classify your data and move the perimeter-bound classes to an in-VPC open-weight deployment. Turn on request-level cost attribution and set budget caps. None of this is exotic. It is the same discipline we already apply to databases, regions, and credentials, finally pointed at the model layer.

The models will keep getting better, and they will keep getting pulled, deprecated, repriced, and re-aliased. Design for the version that disappears, and the upgrades take care of themselves.

Has anyone actually rehearsed a provider-down failover, or did you find out it worked the hard way?

A team I know burned through a quarter's model budget in the first eleven days of the quarter. Nobody was being reckless. A retrieval feature shipped, an agent started looping on a class of documents nobody had tested at scale, and every retry called the most expensive model in the catalog. The dashboard that would have caught it did not exist, because for LLM spend almost nobody has built one yet.

That is the whole problem in one sentence. Cloud FinOps taught us the drill. Tag everything. Attribute cost to a team. Set a budget. Alert before you blow it. Review weekly. Then generative AI arrived and we threw all of it out the window. The FinOps Foundation named AI cost management the top wanted skill for 2026, and reports that about 98% of organizations are now managing AI spend. "Managing" is generous. Most are receiving an invoice and reacting to it.

And AI spend is harder to govern than EC2, not easier. A virtual machine has a predictable hourly rate. A model call has a cost that depends on input tokens, output tokens, the model you happened to route to, whether you cached the context, and how many times an agent decided to retry. The unit of spend is the request, and requests are generated by code, increasingly by autonomous agents making their own decisions. You cannot manage what you cannot see at that granularity, and until very recently you could not see it at all.

Start by metering the request, not the bill

The first move is to get cost attribution down to the individual call. Without it, every other control is guesswork.

The platforms finally caught up in May. Amazon Bedrock added request-level usage attribution on May 20, 2026, so you can tag an inference profile and get usage broken out per request rather than as one undifferentiated monthly total. Microsoft, which renamed Azure AI Foundry to Microsoft Foundry effective January 1, 2026, shipped project-level cost attribution on May 31. Turn both on. They are detailed billing and cost allocation tags, one platform over. You would never run production cloud without those, and you should not run production AI without these.

Platform attribution alone is not enough, because your real cost driver is usually your own application logic. The durable place to meter is your gateway. If you serve LLMs at any scale, every call should route through a single internal gateway or proxy, not forty services each holding their own API keys and calling providers directly. The gateway is where you stamp each request with the metadata that matters: which team, which feature, which agent, which model, input and output token counts, and a derived cost. Emit that as a structured event into your existing observability pipeline. Now you have a per-request cost record you own, independent of any one vendor's billing format, and you can join it to the rest of your telemetry.

One caution while you are wiring this up. Apply the same secret hygiene here that you apply everywhere else. GitGuardian found 1,275,105 AI secrets sitting in public GitHub repositories in 2025, up 81% year over year. A gateway with centralized, rotatable keys is also how you stop forty copies of a provider key from leaking into forty repos.

Route to the minimum effective intelligence

Once you can see cost per request, the biggest single lever is routing. The principle I use is minimum effective intelligence: send each task to the cheapest model that still produces an accepted result, and escalate only when the cheap model fails an explicit quality check.

Most teams do the opposite. They pick the strongest model in the catalog, point everything at it, and never revisit the decision. That is the AI equivalent of running every workload on your largest instance type because it is simpler. It works, and it is enormously wasteful.

Concretely, tier your traffic. Classification, extraction, short rewrites, and routing decisions almost never need a frontier model. Reserve the expensive models for genuinely hard reasoning and let a cheaper model handle the long tail. Newer model controls help here. Claude Opus 4.8, which shipped on May 28, 2026, added a user-selectable effort control, so you can dial reasoning depth down for tasks that do not need it instead of paying for maximum effort on every call. Build an evaluation harness that measures whether the cheaper path actually passes, then escalate on failure. The escalation logic lives in the same gateway that does your metering, which is exactly why the gateway is the right place to invest.

There is a second reason to keep the routing layer flexible. GPT-5.5 Instant became the ChatGPT default on May 5, 2026, exposed through a floating "chat-latest" alias. Pin your application to a floating alias and your cost and behavior can change underneath you without a deploy on your side. Pin to stable model ids, like "claude-opus-4-8", and make model selection a config decision your routing layer owns rather than an accident of whatever the provider promoted to default this week.

Treat caps as a control plane, not a hope

Attribution tells you what happened. Caps stop the eleven-day budget fire from happening at all.

A budget you only read about after the fact is a postmortem, not a control. Enforce the limit where the request flows, at the gateway. Give every team, feature, and agent a spend budget. Track running spend against it in a fast store. When a caller crosses a soft threshold, alert. When it crosses the hard cap, the gateway refuses or downgrades the request rather than forwarding it. This is the same discipline as an AWS Budgets action that triggers automatically, except you are enforcing it inline on the path that actually spends the money, so it bites in seconds rather than after the daily billing refresh.

Set the alert thresholds where they give you time to act, not where they confirm the disaster. A burn-rate alert that fires when a team is on pace to exceed its monthly budget by day ten is worth ten dashboards nobody opens.

Tag agents like cost centers, and review weekly

The last piece is organizational, and it is where the FinOps analogy becomes exact.

Autonomous agents are the new spend-generating workloads, and they behave like services with their own budgets and their own blast radius. So give each agent an identity and a cost center, the same way you would tag a service. This is not only a finance concern. The Cloud Security Alliance, in its non-human identity governance whitepaper on May 20, 2026, noted that non-human identities already outnumber humans by roughly 45 to 1, and as high as 144 to 1 in some estimates. Every one of those agents can spend money and take action. Naming and budgeting them is the same hygiene that lets you both attribute cost and revoke access cleanly.

Then put it on a cadence. The cloud FinOps shops that control spend do it with a boring weekly review: top movers, biggest cost-per-outcome offenders, anything new that appeared, anything trending toward its cap. Run the identical meeting for AI. Pull the per-request data from your gateway, look at cost per accepted result rather than raw token volume, and ask one question of every line that grew. Is this buying us proportional value.

None of this is novel. It is the cloud FinOps playbook applied to a new unit of consumption. The teams that get hurt are the ones who assume AI spend is a model problem and forget it is an operations problem. The meter is already running. The only question is whether you have built the dashboard yet.

I am curious where others are putting the metering: at the gateway, at the provider, or both. What is working for you.

Count the humans with logins in your environment. Now count the service accounts, CI runners, API keys, OAuth integrations, and lately the AI agents acting on someone's behalf. The second number is not close. In its non-human identity governance whitepaper from May 2026, the Cloud Security Alliance put the ratio at roughly 45 to 1, and as high as 144 to 1 in some estimates. You already run a workforce that is overwhelmingly machine. Almost no one is governing it like one.

Let me be precise about the failure mode, because "AI security" gets discussed at a level of abstraction that is useless on a Monday morning. The problem is not that agents are dangerous in some science-fiction sense. It is narrow and mechanical: your agents can authenticate, but they cannot prove they are authorized. And every compliance framework you are graded against was written for humans who can.

Authentication is solved. Authorization is the hole.

When a person joins, they get an identity, an entitlement set tied to a role, an approval trail, an offboarding date, and an access review every quarter. Authentication tells the system who is knocking. Authorization tells it what they may do once inside. For humans we built an entire lifecycle around the second question.

Agents skip it. An agent presents a token and the token works. There is no role attached to the agent as a principal, no joiner-mover-leaver process, no quarterly review asking whether this thing should still be able to read the customer table. The credential is the entire identity.

That is why GitGuardian found 1,275,105 AI-related secrets sitting in public GitHub repositories in 2025, up 81 percent year over year. Secrets sprawl is not a hygiene problem you nag developers about. It is the predictable result of treating long-lived credentials as if they were identities, then handing them to software that copies, logs, and forwards them at machine speed.

The blast radius is not theoretical either. There is a widely circulated account of an AI coding agent that deleted a startup's production database, and the volume-level backups along with it, in roughly nine seconds. Whether or not every detail is exact, the shape is right: an over-permissioned non-human principal, a standing credential, and no authorization boundary between "help me" and "destroy everything." A human with that much standing access would have tripped three separate controls. The agent tripped none.

Why your frameworks do not catch this

Pull up your SOC 2 or HIPAA IAM controls and read them as if a machine were the subject. Access provisioning assumes a request and an approver. Periodic access review assumes a reviewer who recognizes the user. Termination assumes a person who leaves. Least privilege assumes a role. An agent that a developer spun up last Tuesday, gave a personal access token, and wired into three internal APIs satisfies the letter of none of these, and breaks the spirit of all of them.

This is the gap regulators are starting to name. The US Treasury published a Financial Services AI Risk Management Framework in February 2026, with 230 control objectives across seven domains. NIST released a preliminary Cyber AI Profile, IR 8596, in December 2025. The EU AI Act deferred its high-risk Annex III obligations to December 2027, but its general-purpose AI enforcement powers still switch on August 2, 2026, with fines up to three percent of global turnover. The direction is unambiguous. You will be asked to demonstrate governance over machine actors, and "we rotate keys sometimes" will not be an answer.

The mechanism is moving. Use it.

The identity industry has stopped hand-waving and started shipping the primitives you need. In May 2026 Auth0 released an agent-native stack with the right vocabulary: Agent as Principal, making the agent a first-class identity rather than a borrowed human one; a Token Vault; and general availability of authorization for MCP. The European Identity Conference in June converged on OAuth 2.1 plus OpenID AuthZEN, which matters because AuthZEN externalizes the authorization decision into a policy decision point you can audit instead of burying it in application code. Cloudflare shipped scannable API tokens in April with automatic revocation and resource-scoped RBAC, so a leaked token can be caught in a public repo and killed before it is used.

Notice what these have in common. They separate the question of who you are from the question of what you may do right now, and they shorten the lifetime of the answer.

A non-human identity program you can start this quarter

Here is the program I would stand up, in the order I would do it. None of it requires waiting for a vendor.

First, build an agent identity registry. Every non-human principal gets a record: a unique identity, a human owner, the systems it may touch, the data classifications it may see, and an expiry. If it is not in the registry, it does not get a credential. This is your machine equivalent of an HR roster, and nothing else on this list works without it, because you cannot govern what you have not enumerated.

Second, kill standing credentials with just-in-time, scoped issuance. An agent should request access for a task and receive a credential minted for that task, that resource, and that window. The default posture flips from "the agent holds a key" to "the agent asks for permission and gets a narrow grant." This is where Agent-as-Principal and AuthZEN-style policy decisions earn their keep.

Third, vault the tokens. Agents should never see raw long-lived secrets. They reference a vault that injects short-lived material at call time. The vault becomes your chokepoint for rotation, revocation, and logging, instead of secrets being smeared across config files and prompt history.

Fourth, make tokens short-lived, with revocation measured in minutes, not days. This is the control that bounds the nine-second database deletion. If the worst-case credential lifetime is fifteen minutes and you can revoke on signal, a leaked or hijacked agent token is a contained incident rather than a standing liability. Scannable tokens with auto-revocation close the detection-to-kill loop on their own.

Fifth, audit per agent, not per service account. Every action should be attributable to a specific agent identity, its owner, and the grant it was operating under. OWASP mapped prompt injection to six of its ten agentic-AI Top 10 categories in June 2026. When injection turns one of these agents against you, your only forensic hope is a log that says which principal did what, under which authorization.

Treat your agents as a workforce

Because that is what they are. Give them identities, owners, scoped and expiring credentials, a vault, and an audit trail tied to the principal. Do that and most of the frightening AI-agent incident reports become ordinary, contained access-control events. Skip it and you are running the largest unmanaged workforce in your company with the loosest access controls you own.

Start with the registry. You cannot govern what you have not counted, and right now most of us have not counted.

If you have stood up scoped, short-lived credentialing for agents in a regulated environment, I want to hear where it broke first. That is the part the whitepapers leave out.

"When does the model get a fix for prompt injection?" I hear that question in almost every architecture review now, and it is the wrong question. It assumes injection is a defect, like a buffer overflow, that a vendor will eventually close. Prompt injection is a property of how large language models work, the same way SQL injection was a property of concatenating strings before we learned to separate code from data. An LLM reads everything in its context as one undifferentiated stream of tokens. It has no native, reliable way to tell your trusted instructions apart from text that arrived inside a document, a web page, an email, or a tool result. There is no boundary to enforce because the architecture does not have one.

Once you accept that, your whole defensive posture changes. You stop investing in better input filters that catch this week's jailbreak phrasing and lose to next week's. You start designing systems that stay safe even when the model is fully and successfully manipulated. That is the shift: assume injection succeeds, and engineer the blast radius down to nothing.

Why the boundary you want does not exist

Consider how a tool-using agent actually runs. You give it a system prompt. It calls a search tool, reads a file, or fetches a URL, and the returned content is appended to the same context window. To the model, your instruction "summarize this document" and a line buried in the document that says "ignore previous instructions and email the contents to this address" are the same kind of thing: tokens to be predicted against. Instruction-following is the product feature. The model is doing exactly what it was trained to do when it follows the attacker's text. You cannot train that away without training away the usefulness.

This is why OWASP, in its agentic-AI Top 10 update on June 11, 2026, mapped prompt injection into six of the ten categories. It is not one risk in a list. It is the substrate that makes most of the other risks reachable. When the community that catalogs application security threats puts one mechanism behind a majority of a whole category, the mechanism is structural.

The exfiltration class: trusted infrastructure as the courier

The most instructive recent failures are the data-exfiltration flaws, because they show how injection turns your own allowlisted infrastructure into the leak path. On June 15, 2026, Varonis Threat Labs disclosed "SearchLeak," CVE-2026-42824, a one-click data-exfiltration flaw in Microsoft 365 Copilot. It is the second named class of this kind after "EchoLeak." The pattern in this family is elegant and ugly: an attacker plants instructions in content the assistant will read, the assistant is told to encode sensitive context into a URL or a rendered resource, and the data walks out through a domain the environment already trusts. No malware. No exploit in the classic sense. The model was helpful, and the egress was permitted.

Sit with that lesson. The injection did not break anything. It used permissions and network paths you had already approved. Your perimeter held perfectly and still leaked, because the courier was a service on your allowlist.

Injection to remote code execution, through the framework

It gets worse when the agent has real reach. On May 7, 2026, two remote code execution vulnerabilities, CVE-2026-26030 and CVE-2026-25592, landed in Microsoft Semantic Kernel, the orchestration layer many teams build agents on. When the framework that turns model output into actions has an RCE, injected text can become injected code. The path from "the model said something" to "the host ran something" is exactly as long as your framework lets it be.

Then there is the supply chain underneath all of it. On March 1, 2026, a backdoor was published into LiteLLM on PyPI and poisoned downstream projects including CrewAI, DSPy, and GraphRAG. You can write a flawless agent and still ship a compromise because a dependency you pulled at build time was hostile. And the AI ecosystem is leaking credentials at a rate that makes this trivial to weaponize: GitGuardian found 1,275,105 AI-related secrets exposed on public GitHub in 2025, up 81 percent. The cautionary tale that keeps me honest is the coding agent that deleted a startup's production database, and its volume-level backups, in roughly nine seconds. Speed is not your friend when the actor moving fast is confused or hijacked.

Defenses that assume the attacker already won

Here is what I actually build, and what you can start on Monday. None of it tries to stop the model from being fooled. All of it limits what a fooled model can do.

Least-privilege tool scopes. Treat every tool an agent can call as a capability grant and write it down as one. The agent that drafts replies does not get send. The agent that reads a database gets a read-only role scoped to the rows it needs, not the service account that owns the schema. If a tool can take an irreversible or external action, it requires a separate authorization step that a hijacked context cannot satisfy on its own.

Output and egress controls with real DLP. The exfiltration class lives and dies on where data is allowed to go. Constrain outbound destinations to an explicit allowlist, inspect what the agent is about to send before it sends it, and strip or block model-generated URLs and rendered resources that smuggle context out. Assume the model will try to be a courier, and refuse to carry the package.

Content provenance and a quarantine pattern. Tag every token by where it came from: your instructions, the user, or untrusted retrieved content. You cannot make the model honor that boundary, but your orchestration layer can. The dual-LLM and quarantine approach is the strongest version: one privileged model that never sees raw untrusted text and issues actions, and a separate quarantined model that processes the untrusted content and can only return structured, validated data, never free-form instructions back into the privileged path. The untrusted text never touches the thing holding the permissions.

Version pinning and an SBOM for AI frameworks. The LiteLLM lesson is a classic software supply-chain lesson wearing new clothes. Pin exact versions of your model frameworks and their transitive dependencies, generate a software bill of materials for the AI stack specifically, and gate upgrades through review. When you can self-host, do: open-weight models like Gemma 4, released May 1, 2026, give you a path to keep data and inference inside a perimeter that cannot leave it.

And size the problem honestly. The Cloud Security Alliance reported on May 20, 2026 that non-human identities already outnumber humans by roughly 45 to 1, and as high as 144 to 1 in some estimates. Every agent you deploy is another principal with credentials and reach. The governance question is not whether you trust the model. It is what each of these identities is permitted to do on its worst day.

Stop asking when the model gets fixed

Prompt injection is not going to be patched, any more than we patched away the possibility of injecting SQL. We engineered around that by separating code from data and by refusing to grant more privilege than a query needed. The same move works here. Start designing so that a fully compromised model is a contained, boring event instead of a breach.

I would genuinely like to hear how others are drawing the trusted-versus-untrusted boundary in production agent systems. What is working, and where does the quarantine pattern break down for you?

An AI coding agent recently deleted a startup's production database and then deleted its volume-level backups. The whole thing took about nine seconds. No malice, no exotic exploit. The agent had write access to a real system, decided a destructive action was the right next step, and nothing sat between the decision and the disk.

That story gets passed around as a horror anecdote. I read it as a design review. The agent worked exactly as built. What failed was everything around it, and that everything is the part most people skip.

Here is the contrarian claim I will defend: building the agent is the easy 20%. Wiring an agent into a real environment is mostly a control-plane problem, and the control plane is layered, boring, and where the actual engineering lives. If you can stand up a chatbot that calls a few tools in an afternoon, congratulations, you have finished the part that does not matter yet. These are the layers I will not deploy an agent without. None of them requires a research budget.

Scoped tools, not god-mode credentials

The first mistake is handing an agent a broad credential and a broad tool. "Run SQL" is not a tool. It is a loaded weapon with a natural-language trigger. A tool is get_customer_by_id(id) that returns three fields, runs as a role that can only read, and has a row cap.

The threat model is no longer hypothetical. In June, OWASP mapped prompt injection to 6 of the 10 categories in its agentic-AI Top 10. The LiteLLM PyPI supply-chain backdoor poisoned CrewAI, DSPy, and GraphRAG earlier this year. "ClawHavoc" planted malicious skills on a public marketplace. SearchLeak (CVE-2026-42824), the one-click Microsoft 365 Copilot exfiltration flaw disclosed in June, is the second exfiltration class of its kind after EchoLeak. Tool poisoning is real, and the pattern repeats because the model treats retrieved content as instructions: the description of a tool, the data it returns, and the instructions embedded in that data are all attacker-controllable surfaces.

So scope the tool, not just the prompt. Every tool gets least-privilege credentials of its own, a narrow input schema, output limits, and an allowlist of what it can reference. Assume any text the agent reads might be trying to redirect it, because increasingly it is.

A judge at the action boundary

A model deciding to act and a model being allowed to act should be two different things. Put a validator at the boundary where intent becomes effect. This is not the same as asking the model "are you sure?" The judge is a separate check, ideally a different model or a deterministic rule set, that evaluates the proposed action against policy before it executes. Does this write touch a production table? Does the cumulative blast radius of this run exceed a threshold? The judge answers, and only then does the tool fire.

A useful mental model: the agent proposes, the judge disposes, the tool executes. Three roles, never collapsed into one. The same logic that protects you also saves you money. I call it minimum effective intelligence: route each task to the cheapest model that still yields an accepted result. Your judge can often be a smaller, faster model or plain code, because validating a structured action against a policy is a narrower problem than generating it. Attribute cost per request, and cap budgets so a runaway loop bankrupts a line item instead of your quarter.

Run-level observability, not session-level logs

Most teams log conversations. That is the wrong unit. When something goes wrong you do not want a transcript, you want the causal chain: which tool was called, with which arguments, derived from which retrieved document, under which credential, costing how much, and what the judge said before it passed.

Bedrock added request-level usage attribution last month. Microsoft Foundry shipped project-level cost attribution and brought Managed VNet to GA in the same window. These are not finance features. Per-run attribution is how you reconstruct an incident and how you catch the slow-motion failures: the agent that quietly retries a destructive call forty times, or the one whose costs spike because a poisoned document sent it into a loop. The FinOps Foundation named AI cost management the top wanted skill for 2026. The teams who can attribute a dollar to a run are the same teams who can attribute a mistake to a run.

So log the run as a first-class object. Trace ID, tool calls, data lineage, judge verdicts, cost. If your telemetry cannot tell you why the agent did that, you do not have observability. You have a chat history.

Graduated autonomy

Autonomy is not a switch. It is a ladder, and you climb it one rung per capability, after the lower rung has earned trust.

• Read. The agent can observe and report. No writes, anywhere.
• Draft. It produces the change, the email, the query, but a human ships it.
• Staged write. It writes to a sandbox, a branch, a draft record. Real output, no production effect.
• Approved write. It writes to production behind explicit human approval per action or per batch.
• Autonomous, reversible only. It acts on its own, but only for actions you can cleanly undo.

That last rung is the rule the nine-second story violated. Deleting a database is not reversible. Deleting the backups is the opposite of reversible. An agent should never reach unsupervised autonomy for an irreversible action, full stop. Reversibility is the gate. Not confidence, not accuracy, not how good the demo looked.

Most production agents I would actually trust live at "draft" or "approved write" for anything that matters, and "autonomous" only for narrow, idempotent, reversible operations. That is not timidity. That is matching authority to the cost of being wrong.

A kill switch that actually kills

Every agent needs an off switch that a human can hit without a deploy, and it has to cut the thing that does damage: the credentials and the tool access, not just the chat UI.

This is now an identity problem more than a UI problem. The Cloud Security Alliance's May whitepaper put non-human identities at roughly 45 to 1 against humans, as high as 144 to 1 in some estimates. Every agent, every tool, every sub-agent is an identity with permissions. Auth0 shipped an agent-native identity stack with "Agent as Principal" and a token vault; Cloudflare shipped scannable API tokens with auto-revocation and resource-scoped roles; the European Identity Conference converged on OAuth 2.1 plus OpenID AuthZEN. The industry is building those primitives because the old model, a long-lived key in an environment variable, does not survive contact with an autonomous caller. GitGuardian found more than 1.27 million AI secrets on public GitHub last year, up 81%.

Your kill switch should revoke the token, not close the tab. Test it like you test backups, by actually pulling it and confirming the agent goes inert.

You do not control the model. You control the plane.

The protocol layer is converging fast. MCP, A2A, and AG-UI are settling into a stack for how agents discover tools, talk to each other, and talk to users. That means less custom glue, and it means the tool boundary, the agent-to-agent boundary, and the agent-to-human boundary are each becoming standard, inspectable, and therefore something you can put a control plane around. The standardization is not a reason to relax. It is the reason the layers above become both possible and mandatory.

The model itself is a commodity that improves on its own schedule, faster than anyone's roadmap. Opus 4.8 shipped about 41 days after 4.7. Flagships now also disappear on a regulator's timeline, as we saw in June when two were pulled offline within days under an export-control directive. None of that is yours to steer. The plane the model acts through is.

So build that. Scope the tools. Put a judge at the boundary. Log runs, not chats. Climb the autonomy ladder one rung at a time and never give irreversible actions away. Wire a kill switch to the credential, and pull it on purpose to prove it works.

The demo is the easy part. The control plane is the job.

Tell me the first layer you would add, or the one you have watched fail in production.

I keep meeting smart teams that made one decision badly and then stopped revisiting it. They picked a frontier model the way people pick a phone, and now every prompt in the company routes to that one vendor regardless of what the task actually needs. That is not an AI strategy. That is brand loyalty with an API key attached.

If you came up through infrastructure, you already own the right mental model for this. You do not run every workload on the largest instance type. You do not pin every service to one availability zone and call it resilience. You route. You tier. You attribute cost. Model selection deserves the same discipline, and most of the engineering rigor you need is rigor you already have.

Route to minimum effective intelligence, not maximum available intelligence

The idea I use most is minimum effective intelligence routing. Send each task to the cheapest model that still produces an accepted result, and measure acceptance instead of guessing at it.

Most production AI traffic is not hard. Classifying a support ticket, extracting fields from a document, rewriting a paragraph, summarizing a thread. These do not need a flagship reasoning model running at full effort. They need a competent model running cheaply and predictably. Reserve the expensive reasoning passes for the genuinely hard, genuinely high-stakes work.

What makes this newly practical is that effort is now a dial, not just a model choice. Claude Opus 4.8, which shipped on May 28, added a user-selectable effort control. The same capable model can run lean on easy tasks and deep on hard ones, and you decide per request. The open-weight path matters here too. Gemma 4 released on May 1 and gives you a self-hosting option for data that simply cannot leave your perimeter, where the routing decision is also a data-residency decision.

To do this honestly you need per-request cost attribution, which until recently was painful. It is now table stakes. Amazon Bedrock added request-level usage attribution on May 20. Microsoft Foundry, the renamed Azure AI Foundry, shipped project-level cost attribution on May 31. The FinOps Foundation named AI cost management the top wanted skill for 2026, with roughly 98 percent of organizations now actively managing AI spend. The tooling caught up. Use it.

Concrete first step: instrument every model call with a task tag, a model id, an effort level, and a cost. Within a week you will find a cluster of high-volume, low-difficulty calls quietly running on your most expensive configuration. Move those down a tier and watch nothing break.

The floating alias is a production dependency you did not declare

An alias is not a version. GPT-5.5 Instant became the ChatGPT default on May 5, exposed as a floating chat-latest alias: convenient, and a pinning risk that should make every platform engineer uncomfortable.

You learned long ago not to run latest tags in production. An unpinned container image means your runtime can change underneath you with no change in your code, no diff, no review, no rollback target. A chat-latest model alias is the same hazard wearing a friendlier name. The vendor can revise the model behind that alias, and your tuned prompts, your evaluation baselines, and your output parsers are all silently dependent on behavior that can shift overnight.

We also got a sharp reminder that model availability itself is not guaranteed. Fable 5 and Mythos 5 launched on June 9 and were suspended on June 12 under a US export-control directive. That was the first time a major US-lab flagship was pulled offline within days of launch. If your system had hard-wired itself to a single model with no fallback, that was an outage you did not cause and could not fix.

So pin. Opus 4.8 exposes a stable API id, claude-opus-4-8. Use the stable identifier in anything that runs in production. Treat a model version like a dependency in a lockfile. Keep a known-good pinned version, test new versions against your own evaluation suite before promotion, and keep a fallback model wired in so a suspension or a rate-limit event degrades gracefully instead of failing hard. Floating aliases are fine in a scratchpad. They do not belong on a critical path.

Evaluate for honesty, not just for the leaderboard

Benchmark scores tell you what a model can do on a good day. They tell you almost nothing about how it behaves when it does not know the answer, and that second property is the one that hurts you in regulated environments.

In the work I do, a model that confidently fabricates is more dangerous than one that is slightly less capable but reliably flags its own uncertainty. A wrong answer delivered with full confidence skips right past human review, because the humans have no signal that anything is wrong. An answer that says "I am not certain, here is why, here is what would confirm it" routes itself to the right reviewer. That behavior is worth more than a few points on a reasoning benchmark.

So build it into your evaluation. Alongside accuracy, score calibration. Feed the model questions where the honest answer is "I do not have enough information." Reward abstention and uncertainty-flagging. Penalize confident fabrication harder than you penalize an honest "I do not know." Track refusal and hedging behavior over versions, because that behavior drifts, and it drifts in ways no published benchmark will warn you about.

This is also where governance is heading, so you are not gold-plating. The US Treasury published a Financial Services AI RMF on February 19 with 230 control objectives across seven domains. NIST released a preliminary Cyber AI Profile, IR 8596, on December 16. Texas TRAIGA has been in force since January 1 with a NIST AI RMF safe harbor. Every one of these frameworks cares how your system behaves under uncertainty, not just how it scores on a clean test set. And the regulatory clock is real. EU AI Act GPAI enforcement powers still activate on August 2, with fines up to 3 percent of global turnover, even though the high-risk Annex III obligations slid to December 2027.

A decision framework you can write down

Strip away the vendor noise and the whole thing reduces to three columns. For each task, decide a risk tier, then map that tier to a model, an effort level, and a pinned version.

• Tier 0, low risk and high volume. Internal drafting, classification, summarization. Cheapest competent model, low effort, pinned version, no human in the loop. Optimize for cost per accepted result.
• Tier 1, moderate risk. Customer-facing text, anything that influences a decision. Mid-tier model, moderate effort, pinned version, sampled human review, calibration tracked.
• Tier 2, high risk and regulated. Anything touching money, health, legal exposure, or a control objective. Strongest model, high effort, pinned version, mandatory human review, full logging and cost attribution, and a documented fallback model. For data that cannot leave the perimeter, a self-hosted open-weight option such as Gemma 4 instead of an external API.

Write that table down. Put it in your repo next to your architecture decision records. Make adding a new AI feature start with the question "what tier is this," the same way adding a new service starts with "what does this need to scale to." The framework is boring, and boring is the point. Boring is what survives a model getting suspended three days after launch.

Choosing a model is a routing decision

It is not a statement of allegiance. It is a routing decision, a capacity decision, and a risk decision, and you already know how to make all three. Tier your tasks. Route to minimum effective intelligence. Pin your versions and keep a fallback. Evaluate for honesty as seriously as you evaluate for capability. Do that and the next suspension is a config change instead of an outage.

I am curious where others have landed on the floating-alias question. Do you pin every production call to a stable id, or accept the drift for some classes of work? Tell me how you drew that line.

Ransomware recovery isn't really a backup problem. It's a backups-you've-tested problem. The distinction sounds pedantic until you're standing in an incident bridge at 2 a.m. asking how old the last clean restore point is, whether the attacker had the access to corrupt it too, and how long a full rebuild actually takes when nobody's done it end to end. The backup is the artifact. The restore is the capability. You only own the one you've exercised.

Assume the attacker is already inside your backups

Most backup strategies are designed for the wrong adversary. They're built to survive hardware failure and human error, events that are random and don't fight back. Ransomware is not random and it fights back. A competent operator lives in your environment for days or weeks before they pull the trigger, and one of the first things they go after is your ability to recover. They find the backup service account. They delete snapshots. They quietly extend the dwell time until your clean restore points have rolled off retention. By the time the encryption starts, the recovery plan you were counting on is already gone.

So the design question is not whether you have copies, but whether an attacker holding your most privileged credentials can destroy your ability to recover. If the answer is yes, what you have is a false sense of a backup strategy, and everything that matters in cyber-resilience flows from closing that gap.

On AWS the public building blocks are well understood, and the point is to compose them deliberately rather than trust defaults. Immutability comes first. S3 Object Lock in compliance mode and Backup Vault Lock let you write recovery data that literally cannot be deleted or altered before its retention expires: not by an admin, not by the root user, not by an attacker holding your keys. That's the property that defeats the "delete the backups" playbook. If a privileged credential can shorten retention or unlock the vault, it isn't immutable; it's just inconvenient to delete.

Isolation comes second. Backups that live in the same account and the same blast radius as production are backups that share production's compromise. The pattern is a separate, locked-down recovery account in its own organizational boundary, cross-account copies pushed into it rather than pulled, and a control plane the production identities can't reach. It is an air gap implemented with IAM and account boundaries instead of a physical disconnect. The recovery environment should be boring, sparse, and almost nobody should have standing access to it.

Recovery into a clean room comes third. When you restore, you do not restore into the environment that just got owned. You stand up an isolated VPC, no peering, no shared services, restricted egress, and you bring data back there to validate it before it touches anything that matters. Ransomware loves a hasty restore straight into the production blast radius, where you helpfully reintroduce the malware along with the data and hand the attacker a second turn. The clean room is where you confirm what's actually clean.

The drill is the product

All of that architecture is theory until you've run the detection-to-restore drill on a calendar, before a real event forces it. Not a tabletop where people talk through what they'd do. An actual game day where you take a real workload, pretend its production data is gone, and rebuild it from immutable backups into the clean room while a clock runs.

That exercise surfaces the things no architecture diagram will tell you. The restore that takes eleven hours because nobody sized the throughput. The IAM role that doesn't exist in the recovery account because it was created by hand in prod and never codified. The database that comes back but won't start because a dependency lives in a service you forgot to include. The DNS cutover nobody owns. The runbook that assumes a person who left the company. You want to find every one of these on a Tuesday with coffee, not during an incident with your name on the bridge.

The drill is also where two numbers stop being aspirational and become real: your recovery time objective and your recovery point objective. RTO and RPO are measurements you take with a stopwatch and then close the gap on, not values you declare in a policy document. If you've never timed a full restore, your RTO is fiction, and fiction is exactly what gets exposed when the people you serve — in our case the 1,500-plus financial institutions that depend on us — are waiting to know when their data is coming back.

The date you should be able to name

None of this needs a bigger backup budget or a fancier tool. Immutability, account isolation, and a clean-room recovery path are public AWS primitives, wired together under one assumption: the attacker already has your keys and is coming for your ability to recover. The rest is the discipline to rehearse the restore until it's muscle memory.

So don't ask your team whether you have backups. You already know that answer and it's worthless. Ask when you last restored a production-scale workload from an immutable copy into an isolated environment, end to end, with a clock running. If nobody can name the date, that drill is the most important thing on your roadmap, and the next destructive event will schedule it for you on far worse terms.

Here is the number that matters more. Map each of those tools to the control it actually delivers — the security outcome it exists to produce — and the list collapses. In every stack I have walked, the tools outnumber the distinct controls by an order of magnitude. Seventy tools, nine controls. The other sixty-one are overlap, redundancy, and things bought to make a specific person feel better in a specific quarter.

The instinct, when the stack feels incoherent, is to buy one more thing to tie it together. I want to argue for the opposite discipline: rationalize by control coverage and integration cost, never by feature lists. The license fee is the cheapest part of a security tool. The expensive part is the integration engineering, the console staffing, and the alert fatigue, and none of those appear on the order form.

Count the controls, not the tools

Start with the mapping exercise, because it reframes everything that follows. A control is a security outcome, not a product. "Detect malicious activity on the endpoint" is a control. Whatever you bought to do it is a tool. The point of the exercise is to stop letting vendors define your architecture by their product categories and start defining it by the outcomes you are accountable for.

When I do this, the seventy tools sort into a short list of control families. The exact taxonomy matters less than the fact that it is short. The 18 CIS Controls or the NIST CSF functions will get you there just as well. The families I keep landing on look like this:

• Identity and access. SSO, MFA, identity governance, privileged access, and the non-human identities nobody inventoried. This is where the largest tool count and the largest real risk both tend to live.
• Endpoint protection and response. The agent on the laptop and the server. One control. Frequently two or three products, sometimes fighting each other for the same hooks.
• Network and perimeter. Firewalls, WAF, segmentation, egress control.
• Vulnerability and configuration management. Scanners, patch orchestration, and cloud posture management, which is the same control pointed at a different substrate.
• Data protection. Classification, DLP, encryption, and key management.
• Detection and response. Log aggregation, the SIEM, the SOAR playbooks, the telemetry pipeline.
• Email and web. The secure gateway, the phishing controls, the browser-isolation experiment someone is still paying for.
• Application and code security. Static and dynamic analysis, software composition, secrets scanning in the pipeline.
• Governance and evidence. The GRC platform, the policy manager, the thing that produces audit artifacts.

Nine families. Seventy tools. Sorted this way the redundancy stops hiding and becomes the whole picture: three products in the vulnerability family that overlap on most of their coverage, two endpoint agents because a migration was never finished, a posture tool per cloud when one would span both. You do not find this in a feature comparison. You find it in the mapping.

The cost is integration, not the license

Sprawl is expensive for reasons that have almost nothing to do with subscription fees, which is why cutting it by hunting for the cheapest renewals never works. The real cost of a security tool is its fully loaded cost of ownership, and three components dominate.

The first is integration engineering. Every tool has to be wired into your identity provider, your logging pipeline, your ticketing system, and your data model, then kept wired as all four of those change underneath it. That is standing engineering work, and it scales with the number of tools, not the number of controls. Ten products in one control family means ten integrations to build and ten to maintain, for one outcome.

The second is console staffing. Every pane of glass implies a human who is fluent in it, who knows its quirks, tunes its rules, and triages its alerts at two in the morning. A small team cannot be expert in seventy consoles, so most of them get watched badly or not at all, which means you are paying for coverage you do not have. A tool nobody has the attention to operate is a line item and a false sense of security, not a control.

The third is alert fatigue, and it is the one that quietly breaks detection. Every redundant tool adds its own stream of findings, most of them low-signal, all of them competing for the same analyst attention. The widely cited pattern in security operations is that a large fraction of alerts are never reviewed, and duplicate tooling makes that worse by design: the same event arrives three times, scored three different ways, and the analyst learns to ignore all three. You did not buy more security. You bought more noise to hide the signal in.

This is where a cost-transparency discipline earns its keep. The TBM framework — Technology Business Management — exists to map spend to the capabilities it delivers rather than to the vendors it flows to. Apply that lens to the security stack and you stop asking what a tool costs and start asking what a control costs, all in, across every tool that touches it. That number is the one worth defending in a budget review, and it is almost never the number on the invoice.

Rationalize by coverage and overlap, not feature lists

Once the tools are mapped to controls and loaded with their real cost, the rationalization is a portfolio decision, and there is a serviceable framework for it borrowed from application portfolio management: Gartner's TIME model — Tolerate, Invest, Migrate, Eliminate. Run each tool through it, but make the sort on control coverage and integration cost, never on which product has the longer feature list.

1. Invest in the tool that covers the most of a control family with the fewest integration seams. Depth and native reach beat a marginal feature the competitor demoed well.
2. Migrate the workloads off the overlapping products in that family onto the one you chose to invest in, deliberately, proving coverage as you go.
3. Eliminate the redundant tool only after the coverage is proven, never before, because a gap you created is worse than the overlap you were trying to remove.
4. Tolerate the handful of point solutions that genuinely have no substitute and no overlap. Every stack has a few. The goal is to shrink that list honestly, not to pretend it is empty.

The feature list is the trap in every one of these decisions. Vendors compete on features because features are what fit in a demo, and a security team under pressure will rationalize keeping a second tool because it does one thing the first one does not. Almost always, that one thing is not a control you are accountable for. It is a nice-to-have that costs a full integration and a full console to keep. Coverage of the outcomes you own is the only feature that counts.

Overlap is not defense in depth

The objection I hear every time is that overlap is defense in depth, and cutting it weakens the program. This deserves a real answer, because defense in depth is a genuine principle and it is also the most abused phrase in security budgeting.

Defense in depth means deliberately layering controls that fail in different ways, so that when one is bypassed another still holds. Two independent controls across two different failure modes is depth. Two endpoint agents from two vendors, running on the same host, fighting for the same kernel hooks, tuned by the same overworked analyst, is one failure mode covered twice, plus a second agent's worth of instability and cost. Accidental redundancy is a single point of failure you are paying double to maintain.

The honest test is whether the overlap was designed or inherited. Designed redundancy, a second detection path chosen on purpose to catch what the first misses, earns its place. Inherited redundancy, two tools in the same family because a migration stalled or a champion left, is cost wearing the costume of prudence. Most of the overlap you will find is the inherited kind, and calling it defense in depth is how it survives every budget cycle.

What consolidation actually buys

A smaller, coherent stack is not merely cheaper. It is more secure and more defensible, and both of those matter more in regulated work than the savings do.

Start with attack surface. Every tool in the stack is itself a non-human identity with standing, privileged access to your environment: an API key, a service principal, a set of read permissions across your accounts. Seventy tools is seventy vendors inside your perimeter, seventy supply-chain relationships, seventy credentials that can be stolen or misused. Consolidation is not only a budget move. It is a reduction in the number of trusted third parties who can hurt you, and that framing lands with a board in a way a savings number does not.

Then there is the audit story. I run security and DevOps for a fintech that serves more than 1,500 financial institutions, which means our controls get examined by people paid to be skeptical: SOC 2 auditors, FFIEC-minded partners, due-diligence teams. The worst answer to "show me how you manage vulnerabilities" is a tour of four overlapping consoles that mostly agree. The strong answer is one control, one owner, one place the evidence lives. A rationalized stack is easier to attest to because there is less of it to explain, and provable beats claimed every time someone is deciding whether to trust you.

And there is the attention dividend. When the analysts are watching nine coherent control planes instead of seventy consoles, the alerts they see are more likely to be real and the hours they spend are more likely to matter. That is the return that never appears in the FinOps spreadsheet and is worth more than the ones that do.

Where to start

You do not need a consolidation project on the roadmap to begin. You need the inventory and the discipline to read it honestly. Map every security tool you own to the control it delivers, and count the controls. Load each control with its real cost, meaning integration, staffing, and the alerts nobody reads, not its license fee. Invest in one tool per control family, and eliminate the rest only after the coverage is proven. And stop calling inherited redundancy defense in depth.