Step 1: Decide what the agent decides and what the workflow decides

AWS describes the split clearly: the agent decides when to run a workflow and what input to pass, and the workflow runs each step exactly as defined. A refund is a good example. The agent judges that a customer deserves one. The eligibility check, manager approval, and credit then happen in a fixed order every time. Write down which parts of your process need judgment and which are fixed rules. Fixed rules belong in code or workflows, never in a prompt.

Step 2: Expose what you already have

You do not need to rebuild processes to make them agent-ready. On AWS, existing Standard and Express Step Functions workflows can be targets for AgentCore Gateway, and the same idea works for any API you can describe. Start with a small set of well-understood operations, such as checking order status or starting a refund, and describe each one clearly: what it does, what inputs it takes, what it returns.

Step 3: Keep identity out of the model’s hands

One lesson from the MoEngage story is that tenant identity could never become a parameter the model gets to set. If the agent can choose which customer or account an action applies to, a confused or manipulated agent can act on the wrong one. Pass identity from the authenticated session, outside the model’s control, and make the tool reject anything else.

Step 4: Give each agent only the tools it needs

A support agent does not need the same tools as a reporting agent. Run separate tool servers with non-overlapping tool sets so each agent can only reach what its job requires. This limits the damage from mistakes and makes testing easier, since you can verify that a tool outside an agent’s set is refused.

Step 5: Let agents search for tools instead of loading them all

MoEngage found that listing all its tools would have cost more than 20,000 tokens per connection. Their agents instead search for tools by describing a task, and receive only the matches. If you expect dozens or hundreds of tools, add a search step rather than putting the whole catalog in context. It saves cost and helps the model pick correctly.

Step 6: Test the boundaries and log the calls

Write tests that call a tool the agent should not have and confirm it fails. Record every tool call with the agent, the inputs, and the result. When something goes wrong, you will want to see exactly which workflow ran and why.

The takeaway

Reliable agents are mostly about the plumbing around the model. Put fixed rules in workflows, expose them as narrow tools, keep identity out of the model’s reach, and let the model handle judgment. MoEngage estimates the managed approach saved about six months of platform engineering, which is a good reason to build on what you already have.

How to Turn Your Existing Workflows and APIs Into Reliable AI Agent Tools was originally published in Let’s Code Future on Medium, where people are continuing the conversation by highlighting and responding to this story.

A messaging framework turns into a presentation by mapping its hierarchy onto the deck, one level at a time. The positioning statement becomes the title card. Each messaging pillar becomes a section with its own divider. Each proof point under a pillar becomes its own card, with the number in the headline rather than buried in a bullet. The objection handling goes in an appendix the rep can jump to when the buyer raises one. That is the whole method, and it answers the second question people ask about this, the best way to create sales enablement content as a product marketer: build the deck from the framework document, keep the framework document as the source of truth, and judge any tool by whether the hierarchy survives generation or gets flattened into one bullet list per slide.

Flattening is the failure to watch for. Paste a four-pillar framework into a generator and the easy output is twelve slides of four bullets each, every pillar and every proof point given the same visual weight, with the positioning statement reduced to a subtitle. A rep cannot present that. The structure that made the framework useful (a claim and the evidence that holds it up) is the thing that disappears. Canva’s study of 4,000 professionals, published September 15, found that “71% trust AI to build slides, but not to present or tell the story,” and a framework deck is where that gap shows up most clearly, because the story is the hierarchy. The same study found that 91% use AI monthly to build slides and 48% save more than an hour on each one, so the drafting problem is mostly solved. The structure problem is the one left. So I looked at seven tools, PowerPoint with Copilot, Google Slides with Gemini, Canva, Beautiful.ai, Pitch, Plus AI and Gamma, through the eyes of the rep who has to stand up and present the result.

The sample framework and the rep’s four questions

To keep this concrete, here is the sample I would hand each tool. It is written for this piece and describes an imaginary product, an accounts-payable automation tool for mid-market finance teams, so nothing in it is a real claim.

Positioning statement: for finance teams that close the books every month by chasing invoices across email, the product is an accounts-payable system that routes and approves invoices without a human touching the routine ones. Four pillars sit under it. Pillar one is speed of close. Pillar two is audit readiness. Pillar three is fit with the existing ERP. Pillar four is cost per invoice. Each pillar carries two proof points, written as placeholders for a customer quote and a customer number, and the framework ends with five objections and the approved answer to each.

The rep’s four questions, which I used as the judging criteria, are practical ones. Did the four pillars become four sections, or one long run of slides? Did each proof point keep its number as the headline? Can a rep swap a proof point for one from the prospect’s industry in about two minutes, without breaking the layout? And does the result land in the PowerPoint file the field actually presents from? I am not scoring the tools. The right answer depends on what your field team uses on Tuesday morning, and I would rather lay out the tradeoffs than pretend a number settles them.

PowerPoint with Copilot and Google Slides with Gemini

PowerPoint’s advantage is the last question. If the field presents from PowerPoint, every other tool is producing a file that will be opened in PowerPoint eventually, and Copilot works inside the file the rep already has. The September Copilot update matters here more than it looks. Microsoft’s own roundup, dated September 30, lists Skills in Copilot for PowerPoint, which are multi-step workflows packaged as reusable capabilities, with prebuilt ones such as “Sharpen slide titles” and the ability for admins to publish approved Skills to the company. A product marketing team could, in principle, package “turn the framework into the sales deck” as an approved Skill and give it to every rep. Another prebuilt Skill, “Explain this presentation,” is aimed at the person who inherits a deck, which describes every new rep handed the framework deck in their first week. Connectors in Copilot for PowerPoint rolled out in September as well, so the source material does not have to be pasted by hand. Brand Kit with Skills is listed as rolling out in October. Copilot Business is $18 per user per month paid yearly under a promotion that runs to December 31.

The risk with Copilot is hierarchy. A generator drafting from a document leans on whatever structure that document has, so a framework written as a flat Word document is likely to come back as a flat deck. Write the framework with real heading levels, one level per layer of the hierarchy, and the outline has a structure to follow. The proof-point swap is where PowerPoint is strongest: every rep already knows how to replace a number in a text box.

Google Slides with Gemini has the cost argument, because Gemini is included in every Workspace tier and Business Starter is $7 per user per month on monthly billing. Slides is also where product marketing and sales tend to comment on drafts together, and the comment thread is a good place to settle which proof point belongs to which pillar. Two things in the window are worth knowing. Google put the import of PowerPoint files into client-side encrypted Slides into beta on September 24, which matters to regulated sellers, and on September 30 it introduced skills in the Gemini app and Workspace. The limit is the same as with any non-PowerPoint tool: if the field presents from PPTX, the Slides deck becomes a download, and fonts and spacing can shift on the way.

Canva and Beautiful.ai

Canva is the strongest of the seven on visual brand control, with brand kits that keep fonts and colors locked and a new generation of AI features, Canva AI 2.0 and Magic Layers among them, marked “New” on its pricing page. Canva Business is US$250 a year per person. For a messaging framework, Canva is at its best when the deliverable is really a one-page visual summary of the pillars, a leave-behind or a battlecard, where the design carries the hierarchy. It is weaker as a working sales deck. A framework deck changes constantly as proof points get replaced, and a carefully designed layout is easy to break when a rep pastes in a longer customer quote. I would also want a product marketer to check that a pillar did not end up as a decorative heading with its proof points spread across three visual elements the rep has to hunt for.

Beautiful.ai’s smart layouts are the most protective of structure in the set. The slide adapts as content is added, so a proof-point card keeps its shape whether the number is two digits or seven. Its blog in the window was aimed at exactly this buyer: a September 3 post called “The End of ‘One-Size-Fits-All’ Sales Decks” and a September 9 post on features for sales teams, and a September 17 post listing its media-library integrations, including Bynder and Frontify, where enterprise brand assets live. Pro is $14.50 a month billed annually and Team is $40 per user per month billed annually. The tradeoff is the flip side of the protection. Locked layouts keep a pillar section looking right, and they also resist the rep who wants to do something the layout did not anticipate, like putting two proof points side by side for a buyer who asked about both.

Pitch and Plus AI

Pitch is strongest on collaboration around a shared narrative. A messaging framework is a negotiated document (product marketing and sales leadership will both have opinions about pillar three), and Pitch’s workspace is built for several people shaping one story with comments and shared templates. Pitch Agent arrived in May, and in August the company published a post about an MCP for decks. Pricing is in euros: Team at EUR 15 a month billed annually and Business at EUR 20, with a free tier that includes 100 one-time AI credits. The question for a sales org is the last mile. If the field presents from Pitch links, Pitch is a good home for the framework deck. If the field presents from PowerPoint, the export is where you will spend your checking time.

Plus AI works inside Google Slides and PowerPoint, which answers the field-format question by never leaving it. That is its main argument and it is a strong one for a sales org with a fixed toolset: the framework deck is generated in the file format the reps already use, with no export step. Its blog published a September 29 post on converting a document to a presentation with AI, which is close to this use case. Plans run from Basic at $10 a month billed annually to Pro at $20, with a seven-day trial that includes 1,000 AI credits. The limit is that Plus AI inherits its host’s layout system, so the hierarchy question is answered by how well the generated outline maps to the host app’s layouts rather than by a layout engine of its own.

Gamma

Gamma’s relevant feature for this job is the plan step. Its agent asks a few questions about what you are making, shows you its plan, and per the help center “won’t start building until you do.” For a messaging framework that is the moment the hierarchy gets fixed: you can check that the plan has four pillar sections in the right order, each with its proof points as separate cards, and correct it before a single slide exists. Correcting a plan is a lot cheaper than reorganizing twenty generated slides.

The proof-point swap uses AI editing, which in Gamma 5 (in public beta per the help center) is a mode rather than a single button. A rep can select one proof-point card and ask for it rewritten around a healthcare customer’s number, and the rest of the deck stays as it was. The rep can also edit by hand, and the help center says the layout adapts.

On the field-format question, Gamma exports to PowerPoint, and tables now export as real editable tables, with one printed caveat: PowerPoint does not support rounded corners on tables, so they arrive with sharp corners. The broader honest limit is that Gamma is card-based rather than slide-based, so a card with a lot of content can shift layout when it becomes a fixed PowerPoint slide, and I would check every pillar section in the exported file before it goes to the field. One practical note on plans. The sample framework above needs a title card, four section dividers, eight proof-point cards and an objection appendix, which is more than the Free plan’s cap of 10 slides per prompt. Plus raises that cap to 100 for $9 per seat per month billed annually, and Pro at $18 adds detailed analytics, which can show enablement which pillar sections reps open before calls. If the field team lives in Google Slides instead, the export path is a PowerPoint file uploaded to Slides, per the help center. For enablement teams that live in Slack, Gamma links shared in a channel expand into rich previews, and comment notifications arrive as direct messages, which is handy when the framework deck is being argued over in the enablement channel.

What the generator cannot check

One limit applies to all seven tools equally. A messaging framework is a set of claims, and generators are good at making claims sound confident. A proof point that says “cut close time” in the framework can come back as “dramatically cut close time” or with a number attached that nobody supplied. Every tool in this set will dress up a claim if the source is vague, and none of them knows which numbers legal has approved. So the proof-point cards get a product marketer’s line-by-line check against the framework document before the deck reaches a rep, whichever tool built it. That check is the most important step in the whole process, and it is the one people skip when the deck looks finished.

The second shared point is ownership. The framework document should stay the source of truth, and the deck should be regenerated or edited from it, never the other way around. Once reps start editing the deck’s pillars directly, the framework and the deck drift, and six months later the field is presenting a messaging hierarchy that product marketing never approved.

How I would choose

If your field presents from PowerPoint and that will not change, start with Copilot or Plus AI, because the deck never leaves the format. If product marketing and sales leadership need to argue the framework into shape together, Pitch or Google Slides gives that argument a good home. If the deliverable is a designed one-page leave-behind of the pillars, Canva. If protecting the layout from well-meaning reps is the priority, Beautiful.ai.

The one I reach for first is Gamma, mostly because the plan step lets me lock the pillar order before anything is generated, and that is a preference, not a verdict.

Seven tools were handed the same messaging framework, judged by whether the pillars survived as the… was originally published in Let’s Code Future on Medium, where people are continuing the conversation by highlighting and responding to this story.

Executive overview of an air-gapped defense architecture intercepting smart contract exploits at the compiler level.

How deploying highly cleared internal engineers prevents automated smart contract exploits from draining enterprise liquidity

The Machine-Speed Liquidity Crisis and the 20-Minute Catastrophe

At precisely the point where human cognition meets algorithmic execution, enterprise perimeters are fracturing. Consider the visceral operational reality of the October 2026 Binance breach, an event that systematically erased $6.36 billion in a highly orchestrated, state-sponsored extraction. This was not a conventional smash-and-grab characterized by brute-forced passwords or static malware. It was a kinetic, AI-orchestrated siege executed by the TraderTraitor collective that targeted the foundational logic of decentralized infrastructure. Across ten disparate blockchains, capital evaporated at a staggering flight rate of approximately $318 million per minute. Attackers algorithmically raced against human freeze protocols, utilizing automated flash-loans to aggressively borrow ETH against stolen USDT fractions of a second before centralized issuers could parse the initial telemetry (Chainalysis, 2024). While ecosystem partners managed to freeze a portion of the assets, over $2.4 billion was permanently laundered via automated market makers and decentralized borrowing protocols, irreversibly degrading institutional liquidity.

The sheer scale of this financial collapse exposes the fatal illusion of the human-in-the-loop operational model. For decades, security operations centers (SOC) have relied on human verification as the ultimate circuit breaker against systemic breaches. The counter-intuitive production reality of the AI era is that human intervention is no longer a safeguard; it is a critical latency vector. If a multi-billion dollar enterprise architecture requires human authorization to freeze a compromised execution network, the underlying capital will mathematically vanish before the initial anomaly alert is even triaged by a Tier-1 analyst. The extraction occurs at machine speed, exploiting decentralized routing algorithms to obscure funds irrevocably. We have crossed an event horizon where relying on human reaction time equates to immediate gross margin collapse.

📊 Executive Summary: The October 2026 $6.36 billion Binance exploit proves legacy perimeters cannot withstand machine-speed AI extraction. To defend institutional liquidity against $318M/minute flight rates and Token COGS degradation, enterprises must abandon outsourced IT and fund highly cleared, embedded Forward-Deployed Engineering (FDE) teams enforcing autonomous, hardware-isolated multi-party computation.

The velocity of this threat demands an entirely new standard of structural engineering. Traditional perimeters assume a static adversary, but artificial intelligence has fundamentally weaponized digital asset compromise. This asymmetry dictates that legacy defensive mechanisms are obsolete. We can no longer build environments optimized for human convenience and post-incident response. The operational reality of defending sovereign liquidity requires the absolute eradication of human latency from the incident containment lifecycle, shifting the battleground from network endpoints to autonomous, hardware-enforced cryptographic boundaries.

Visualizing the mathematical reality of AI execution speeds bypassing human-in-the-loop SOC protocols, causing severe liquidity drainage.

The Illusion of Perimeter Defense and the Biometric Bypass

Traditional enterprise security models are anchored in identity verification, assuming that if a user possesses the correct biometric markers and hardware tokens, their execution requests are legitimate. Large Multimodal Models (LMMs) have entirely obliterated this assumption through identity virtualization (Vaswani et al., 2017). The deployment of biometrically perfect, real-time deepfakes allows threat actors to bypass Zero-Trust Network Access (ZTNA) with chilling efficiency. A forensic examination of the 2022 AI hologram of Binance’s Chief Communications Officer demonstrates how attackers synthesized live virtual media to socially engineer highly technical project leaders (Hillmann, 2022). By deploying this AI hologram in live virtual meetings, a sophisticated hacking syndicate successfully spoofed authoritative identities to manipulate cryptocurrency project leaders into transferring massive listing fees. Compounded by incidents like the $25.6 million Arup scam — where malicious actors utilized deepfake technology in live video environments to bypass corporate verification — it is clear that generative AI has mastered real-time human manipulation (Lin, 2025). The highest tiers of multi-factor authentication are rendered mathematically useless if the authenticated human operator is actively executing malicious instructions on behalf of an AI simulation.

Beyond the manipulation of human operators, decentralized DevOps pipelines present a fatal structural vulnerability. The anatomy of the 2026 Binance hot wallet failure illustrates how an entire multi-billion dollar architecture collapsed from a single compromised DevOps endpoint. An attacker infiltrated an off-site developer’s laptop, extracting credentials with lateral access to cloud service containers capable of submitting protocol withdrawals. From that vantage point, the threat actors weaponized Ethereum’s EIP-7702 delegation standard (Buterin et al., 2024). Designed originally to optimize user experience by temporarily allowing external accounts to act as smart contracts, EIP-7702 became the perfect vector for destruction. Attackers injected fifty pre-signed authorizations simultaneously, instantly transforming a secure institutional hot wallet into a malicious sweeper contract.

💡 Architectural Implementation Guardrail (ProTip): Architectural Implementation Guardrail: Deploying EIP-7702 without hardware-enforced multi-party computation constraints transforms user experience flexibility into a fatal vulnerability. Temporary smart contract delegations must be continuously validated against air-gapped cryptographic quorums to prevent simultaneous pre-signed payload injection.

Architectural flexibility, when combined with off-site or outsourced engineering teams lacking air-gapped CI/CD anomaly detection, becomes an existential attack vector. The transition from legacy augmentation models to sovereign engineering is not merely an operational preference; it is a structural mandate for institutional survival. In highly regulated sectors, offshore IT augmentations currently exhibit a 78% pilot-to-production failure rate due to compliance friction and supply-chain vulnerabilities.

Demonstrating how AI deepfakes seamlessly bypass ZTNA biometric parameters via EIP-7702 payload injections without triggering legacy alarms.

Architectural Paradigm Identity & Access Trust Model CI/CD Pipeline Telemetry Pilot-to-Production Success Margin & Liability Exposure Legacy IT Augmentation Human-in-the-loop verification, vulnerable to LMM spoofing Reactive static analysis, vulnerable to EIP-7702 container exploits ≈ 22% (High compliance and regulatory friction) Catastrophic SLA breach; reactive treasury drains Sovereign Embedded FDE Cryptographic Multi-Party Computation (MPC), zero biometric reliance Autonomous AI-audited boundaries, hardware-isolated containers > 85% (Pre-cleared, air-gapped deployment) Proactive margin preservation; strict DORA compliance

As the matrix above delineates, the margin and liability exposure inherent in legacy IT augmentation is unsustainable. Reactive telemetry consistently fails against pre-signed protocol exploitation. By contrast, Sovereign Embedded FDE architectures enforce multi-party computation and autonomous kill-switches, entirely removing the spoofable human element from the deployment trust model.

Statutory Collapse and the $10M+ Fiduciary Blast Radius

When technical architectures rot, the consequences bypass the IT department and detonate directly on the C-Suite balance sheet. Global regulators no longer categorize sophisticated smart contract exploits as unavoidable anomalies; they classify them as gross negligence of fiduciary duty. Operating an enterprise without continuous cryptographic validation of internal communications constitutes a direct violation of compliance obligations across SOC 2 Type II and FedRAMP High. Furthermore, the legal blast radius under frameworks like the EU AI Act, the NIST AI Risk Management Framework (RMF), and strict SEC cyber-disclosure rules (Item 1.05 of Form 8-K) (European Parliament & Council of the European Union, 2024; National Institute of Standards and Technology, 2023; Securities and Exchange Commission, 2023) ensures that engineering failures result in catastrophic corporate liabilities. Failing to mathematically isolate service containers from localized endpoint credentials transitions a firm from a victim of cybercrime to a perpetrator of regulatory negligence.

Visualizing how a concentrated AI cyber-event disproportionately collapses treasury reserves, triggering immediate regulatory insolvency.

To absorb these shocks, the digital asset industry has historically relied on the fallacy of the treasury backstop. Platforms frequently reserve massive internal pools of capital — such as Binance’s Secure Asset Fund for Users (SAFU) — to reimburse clients following an exploit. Reimbursing clients from a $6.34 billion treasury reserve does not restore market confidence; it actively masks underlying architectural decay and severely decimates operational liquidity. This reactive strategy broadcasts a dangerous signal to institutional Wall Street investors: the core engineering framework remains fundamentally indefensible against AI-automated exploits (OWASP Foundation, 2023), and the platform expects to be breached again. Burning treasury capital to cover execution failures is the financial equivalent of fighting a chemical fire with enterprise valuation.

🛡️ Executive Risk Calculus & SLA Alert: Under SEC Item 1.05 of Form 8-K and MiCA capital adequacy frameworks, relying on a corporate treasury backstop to cover AI-automated exploits transitions an uninsurable cyber event into gross negligence of fiduciary duty, triggering immediate C-Suite liability.

The ultimate statutory consequence of this systemic fragility is insolvency. Sudden liquidity shocks resulting from automated extraction — where Σ Liabilities > Treasury Liquidity — trigger immediate regulatory receivership. Under stringent capital adequacy frameworks like the European Union’s Markets in Crypto-Assets (MiCA) regulation, an enterprise cannot operate with a multi-billion dollar deficit driven by algorithmic theft. Once a platform crosses that threshold, cyber-insurance policies are routinely voided due to the failure to maintain mandated DORA resilience standards (European Parliament & Council of the European Union, 2022), leaving executives personally liable for the deficit. The survival of the institution requires preempting the blast radius altogether.

The architectural topology of Forward-Deployed Engineering teams enforcing hardware-isolated Multi-Party Computation boundaries.

Air-Gapped and Sovereign: Engineering the FDE Defense Architecture

The antidote to AI-weaponized extraction requires executing a severe pivot from outsourced IT augmentation to the deployment of highly cleared, specialized AI and SecOps internal engineers. These Forward-Deployed Engineering (FDE) teams must embed directly within the enterprise’s air-gapped infrastructure. By physically and logically segregating the deployment lifecycle, enterprises ensure that no external endpoints, offshore contractors, or globally distributed virtual machines can push arbitrary execution code. FDE teams replace reactive human oversight with autonomous, machine-speed countermeasures. If a multi-chain routing algorithm attempts to drain liquidity, the FDE-designed architecture does not send a Slack alert to an analyst; it instantly and autonomously halts the execution state at the compiler level.

This transition relies heavily on the implementation of strict Multi-Party Computation (MPC) pipelines and hardware-enforced boundaries. Code and infrastructure updates are deployed exclusively through an AI-audited MPC enclave, demanding cryptographic quorums that cannot be bypassed by a single compromised credential or deepfaked executive order. Furthermore, hardware-enforced boundary isolation ensures that cloud service containers possess their own autonomous kill-switches, completely isolated from localized endpoint keys. Even if an attacker perfectly spoofs a developer’s biometric identity and bypasses ZTNA, they cannot alter the mathematical constraint physically embedded within the internal signing node.

Figure: Process Flow Architecture Diagram

As illustrated in the operational topography above, this architecture directly neutralizes the vectors that caused the 2026 systemic collapses. A compromised remote endpoint is immediately denied access because it lacks the necessary MPC quorum. An AI deepfake attempting to authorize a transaction fails because the cryptographic signature of the action does not originate from the hardware-isolated constraint node. By entirely removing the human-in-the-loop for emergency freezes and relying purely on deterministic telemetry capable of reacting in Latency < 1s, the FDE-governed MPC pipeline outpaces the adversary.

“It seems probable that once the machine thinking method had started, it would not take long to outstrip our feeble powers.” — Alan Turing (1950)

We can no longer rely on human powers to secure machine-speed markets; we must build sovereign systems that fight automation with deterministic automation.

Margin Preservation at Scale: The FinOps Reality of Sovereign Engineering

Building an embedded FDE defense architecture is not an inexpensive endeavor, and it fundamentally alters enterprise unit economics. CTOs and financial officers must honestly quantify the upfront FinOps commitment, which typically demands $15M to $30M in annual operational expenditure for dedicated sovereign engineering squads and continuous AI model monitoring. However, this upfront investment must be weighed against the catastrophic alternative of a $6.36 billion extraction event. Traditional System Integrators simply cannot deploy complex, AI-driven cryptographic countermeasures with the precision required to halt kinetic threats. In contrast, sovereign FDE models operate with pilot-to-production conversion ratios exceeding 85%. This model generates massive, asymmetric ROI by protecting the balance sheet against irreversible token COGS degradation and the inevitable $10M+ SLA liabilities triggered by platform downtime.

Reframing the FinOps expenditure of internal FDE squads as an aggressive gross margin preservation strategy against algorithmic extraction.

To maintain executive credibility, we must acknowledge the strict engineering trade-offs required by this transition. Sourcing highly cleared, elite SecOps and AI engineers is exceptionally difficult in a talent-scarce market, driving up initial compensation and retention costs. Furthermore, imposing stringent, hardware-backed MPC pipelines temporarily reduces raw deployment velocity. Development teams accustomed to pushing code multiple times a day will encounter necessary friction. This requires a profound cultural shift away from the legacy Silicon Valley ethos of “move fast and break things” toward a mature institutional mandate of “move securely and preserve liquidity.”

1. Establish Embedded Field Ownership. Executive leadership must completely eradicate the dependency on offshore augmentation for critical infrastructure. You must fund and empower internal FDE squads who physically and legally sit within your jurisdictional and operational boundaries. These engineers must own the lifecycle of the smart contract from the compiler to the on-chain settlement, leaving zero surface area for supply-chain injection attacks.

2. Enforce Cryptographic CI/CD. Transition your entire deployment architecture away from static vulnerability scanning toward continuous, AI-audited Multi-Party Computation. Require deterministic mathematical consensus for any state change in production, ensuring that an LMM-driven deepfake cannot leverage social engineering to bypass architectural safeguards. If a command lacks the hardware-enforced MPC signature, the system must drop the execution request instantly.

3. Capitalize the Defense as Margin Preservation. Reframe the $30M FinOps expenditure not as a sunk cost, but as an aggressive gross margin preservation strategy. In an era where a twenty-minute AI exploit can trigger MiCA receivership and wipe billions off a market cap, sovereign engineering is the only mechanism that guarantees continuous operations. Executives must communicate to their boards that funding internal security resilience is now the primary driver of institutional valuation.

“The enterprise perimeter is no longer a geographical network boundary; it is a continuously contested cryptographic execution state. If you rely on human cognition to freeze an automated breach, you have already accepted insolvency.” — Mohit Sewak

The era of trusting vulnerable human cognition to guard machine-speed liquidity has ended. Threat actors are utilizing frontier generative AI to execute algorithmic extraction faster than any human SOC can register. By funding sovereign FDE teams and enforcing strict hardware-isolated computational pipelines, modern enterprises can structurally outmaneuver these automated adversaries, cementing their operational resilience and securing their balance sheets against the next generation of kinetic cyber-threats.

📋 Executive Diagnostic & Inbound Architecture Audit

🛡️ Enterprise Advisory Notice: If your engineering teams are deploying autonomous agentic workflows or prompt-based guardrails without residual stream verification, your balance sheet is actively carrying unquantified SLA and compliance risk. To schedule an executive architecture audit or stress-test your deployment under high concurrency, connect directly with Dr. Mohit Sewak’s enterprise practice.

🚀 The 4-Dispatch AI & Quantum Intelligence Ecosystem

Never miss a breakthrough. Subscribe to our interconnected executive dispatches tailored across boardroom strategy, safety governance, peer-reviewed research, and post-quantum infrastructure:

• 🛡️ AI Safety & Standards Pre-Proposal: Tracking generative AI security, red teaming, and regulatory compliance? Subscribe to our flagship dispatch in Responsible Generative AI. (Current Publication)
• 📈 Boardroom Strategy & Fiduciary ROI: Leading enterprise GenAI implementation & budgeting? Read our latest business playbook in GenAI for Business Leaders.
• 🔬 Deep Technical & arXiv: Want to inspect the formal proofs, benchmarks, and research architecture? Explore Generative AI Research.
• ⚛️ Quantum Security Bridge: Tracking quantum threats to AI security and cryptographic migration? Subscribe to Quantum.

🔔 Secure Your Competitive Edge — Subscribe Today: To maintain an unassailable 360° perspective across C-suite ROI, AI red teaming, benchmark rigor, and post-quantum migration, subscribe to our publications above. Join elite enterprise leaders, standards committee delegates, and senior architects.

Disclaimer: The views and opinions expressed in this article are personal and do not necessarily reflect the official policy or position of any associated agencies, organizations, or the India AI Mission. AI assistance was utilized in the research, drafting, and ideation of this article. Licensed under CC BY-ND 4.0.

📜 Citation & Normative Working Paper Attribution

🏛️ How to Cite (Standards & Academic Attribution): Sewak, M. (2026). [RFC Proposal] Fund Embedded FDE Teams to Stop Binance-Style AI Theft: Normative Threat Taxonomy, Verification Test Harness, and AI Governance Specification (v1.0). CoResearch AI Working Paper Series. Prepared for consideration by ISO/IEC JTC 1/SC 42, NIST AISIC, and BIS LITD 30.

References & Further Reading

Systems & Model Architecture (Foundational Research)

Buterin, V., Wilson, S., Dietrichs, A., & lightclient. (2024). EIP-7702: Set code for EOAs. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-7702

Turing, A. M. (1950). Computing machinery and intelligence. Mind, 59(236), 433–460. https://doi.org/10.1093/mind/LIX.236.433

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, L., & Polosukhin, I. (2017). Attention is all you need. Advances in Neural Information Processing Systems, 30, 5998–6008. https://proceedings.neurips.cc/paper/2017/file/3f5ee243547dee91fbd053c1c4a845aa-Paper.pdf

Enterprise FinOps, Compute & Hardware Telemetry

Chainalysis. (2024). The 2024 crypto crime report. Chainalysis. https://www.chainalysis.com/crypto-crime-report/

Hillmann, P. (2022). Scammers created an AI hologram of me to scam unsuspecting projects. Binance Blog. https://www.binance.com/en/blog/ecosystem/scammers-created-an-ai-hologram-of-me-to-scam-unsuspecting-projects-7313337985392095982

Lin, L. S. F. (2025). Organisational challenges in US law enforcement’s response to AI-driven cybercrime and deepfake fraud. Laws, 14(4), 46. https://doi.org/10.3390/laws14040046

Threat Modeling, Guardrails & Risk Governance Standards

European Parliament & Council of the European Union. (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011 (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 1–79.

European Parliament & Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689.

National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST Trustworthy and Responsible AI Report 100–1). U.S. Department of Commerce. https://doi.org/10.6028/NIST.AI.100-1

OWASP Foundation. (2023). OWASP top 10 for large language model applications. OWASP. https://owasp.org/www-project-top-10-for-large-language-model-applications/

Securities and Exchange Commission. (2023). Cybersecurity risk management, strategy, governance, and incident disclosure (Release Nos. 33–11216; 34–97989). U.S. Securities and Exchange Commission. https://www.sec.gov/files/rules/final/2023/33-11216.pdf

Fund Embedded FDE Teams to Stop Binance-Style AI Theft was originally published in Let’s Code Future on Medium, where people are continuing the conversation by highlighting and responding to this story.

On January 14, 2025, Lenny’s Newsletter published “Introducing Core 4: The best way to measure and improve your product velocity,” a guest post by Laura Tacho, CTO of DX, presenting a scorecard she co-authored with Abi Noda alongside Nicole Forsgren, Margaret-Anne Storey and Michaela Greiler, built on what she described as “field experience at over 300 companies,” with Dropbox, Vercel and Intercom among the early adopters. It has four dimensions, Speed, Effectiveness, Quality and Impact, which Tacho says are “designed to hold each other in tension.” The contested choice was the Speed metric: pull requests per engineer, a number Meta, Microsoft and Uber were already using, which she defended as “used only as a system health metric, and always alongside other metrics in the framework.” The ROI math came from DX data on 40,000 developers across 800 organizations: “Improving the Effectiveness score (DXI) by one point translates to saving 13 minutes per week per developer, equivalent to 10 hours annually.” Her case study was a 150-engineer organization that targeted a 25 percent cut in a four-hour PR cycle time and landed “the actual reduction of PR cycle time coming in around 40%” at 6.6 PRs per engineer per week.

That was twenty-one months ago, before Claude Code and Codex were products anyone outside a lab had used, and I want to read the scorecard against what has happened since. My argument is that Core 4 has aged better than almost any engineering measurement proposal of its era, for a reason its authors could not have fully anticipated. The dimension everyone argued about, Speed, has become nearly free. The three dimensions nobody argued about, Effectiveness, Quality and Impact, were the counterweights, and in October 2026 the counterweights are the entire point. A product manager who negotiates with an engineering organization using this scorecard today should be looking at the three quiet numbers and treating the loud one as a warning light rather than a goal.

What the January 2025 argument was about

It is worth remembering why PRs per engineer was controversial, because the objection has flipped. In early 2025 the worry was that counting pull requests would pressure engineers to slice work into smaller, more numerous changes to inflate a number, and that managers would read the number as individual productivity. Tacho’s defense was structural. The metric was never meant to stand alone; it was a system health signal, read beside Effectiveness (a survey-based developer experience index), Quality (change failure rate and similar) and Impact (the share of engineering time going to new capabilities rather than maintenance). The tension between the four was the design. If Speed rose while Quality fell, the scorecard was supposed to make that visible rather than celebrate the Speed.

The case study shows the intended use. The 150-engineer organization measured a four-hour PR cycle time, calculated that a 25 percent cut was worth about a thousand waiting hours a week, invested in the review process, and came in around 40 percent at 6.6 PRs per engineer per week. Tacho priced two developers’ weekly salary at $9,600 to arrive at roughly half a million dollars a year of recovered time. That is a sensible piece of arithmetic for a world in which an engineer writes a pull request, waits for a person to review it, and the waiting is the waste.

Guillermo Rauch’s line in the piece, “With scale-ups, you live or die by velocity,” was the ambient belief of the time, and I do not think anyone would have called it controversial. Velocity was scarce. Measuring it carefully was the responsible thing to do.

Then Speed became free

The number that changed the arithmetic came from Boris Cherny, who leads Claude Code at Anthropic, on Lenny’s Podcast in February 2026. Across the company, he said, “Productivity per engineer has increased 200%” measured in pull requests, while headcount roughly quadrupled. His own figure was more extreme: “100% of my code is written by Claude Code. I have not edited a single line by hand since November,” shipping ten to thirty pull requests a day with five agents running. Ramp’s product chief reported in September that an in-house agent writes three quarters of the company’s PRs. The specifics vary by company and I would not generalize from Anthropic’s internal numbers to anyone else’s, but the direction is not in dispute. Pull requests per engineer, the Speed metric Core 4 chose, has gone from a number a team worked a quarter to move by 40 percent to a number an agent can triple by Friday.

Consider what that does to the scorecard. In January 2025 a rise in PRs per engineer meant that the review process had improved, or that engineers were less blocked, or that the work had been sliced more finely. In October 2026 a rise in PRs per engineer most likely means someone installed a coding agent. The number still moves, and it still appears in the Speed column, and it now measures tool adoption rather than system health. A dashboard that shows Speed up 200 percent is telling you that agents are present. It is not telling you whether the organization is faster in any sense a customer would notice.

Worse, the metric now has a structural bias toward looking good. An agent producing many small pull requests, each one plausible, will drive the Speed dimension up regardless of whether the changes were needed, whether they were reviewed, or whether they introduced regressions that surface weeks later. The old worry, that engineers would game the number by slicing work, has been automated. Nobody has to game it. The tooling does it by default.

The three quiet dimensions become the whole scorecard

This is where I think Core 4 looks better in 2026 than it did on launch day, and where the authors’ insistence on tension pays off. If Speed is a warning light, the question becomes what the other three say.

Effectiveness is a survey. Tacho’s DXI measures how developers experience their own work: whether they are blocked, whether the tooling helps, whether they can get into a flow. It was always the dimension that engineers trusted and executives found soft. It is now the dimension that can tell you whether the agents are helping or merely producing. If PRs per engineer has tripled and the Effectiveness score has not moved, the engineers are spending the time they saved on writing code reviewing what the agents wrote, and the organization has traded one kind of work for another without a net gain. Nicole Forsgren, one of the Core 4 co-authors, said on Lenny’s Podcast, in a conversation the archive dates to October 2025 though the recording appears to be older, that “About 50% of your time now is spent reviewing versus writing.” A survey is how you find out whether that number has gone to 80, because the pull request count will not tell you.

Quality is the dimension that should scare people most. Change failure rate and time to restore were always the counterweights to Speed, and in a world where Speed was earned slowly, they moved slowly too. In a world where an agent can raise PR volume by multiples in a week, Quality is the only dimension that can show you the cost in anything like real time, and it will show it late, because regressions surface after deployment. A PM reading the scorecard should expect Quality to lag Speed by a release cycle, and should treat a quarter in which Speed jumped and Quality held steady as not yet proven rather than as a win.

Impact, the share of engineering time spent on new capabilities as opposed to maintenance and toil, is the subtle one, and Tacho was careful in 2025 to say that more is not always better. In 2026 I would add a second caution. Agents are very good at producing the kind of work that counts as new capability: features, endpoints, screens. They are less reliably good at the maintenance work that keeps a system healthy, partly because that work is harder to specify. An organization whose Impact share has risen sharply since adopting agents may have an agent fleet generating new surface area faster than anyone is maintaining the old. That is a real risk and the Impact number, read naively, would call it progress.

What the PM negotiates with now

Core 4 was pitched as the scorecard a product leader and an engineering leader could both read, and that remains its practical value. The negotiation has changed shape.

In 2025, a PM used the scorecard to argue for investment in the delivery system: better review, less waiting, fewer blockers. The case study is that negotiation, with a dollar figure attached. In 2026, the PM’s position is closer to the opposite. The engineering organization will arrive with a Speed number that has gone vertical and a reasonable belief that this is good news. The PM’s job is to ask what the other three columns say, and to refuse to accept Speed as evidence of anything until they do.

Concretely, I would ask for the scorecard with Speed moved to the bottom. I would ask that the Effectiveness survey run more often than quarterly during any period when agent adoption is changing, because quarterly is too slow to catch a review burden that doubles in a month. I would ask that Quality be reported with a lag indicator, so that this quarter’s Speed is read against next quarter’s change failure rate rather than this quarter’s. And I would ask that PRs per engineer be reported with a breakdown by author type, agent and human, so that the number can be read at all. A PR count that mixes the two is a sum of unlike things.

The earlier measurements of the review queue, the one that showed review becoming the bottleneck and the one that showed agents reviewing agents in about a minute, are the mechanism underneath all of this and I will not restate them. The scorecard is where that mechanism becomes a conversation between two leaders with a shared sheet.

Reading the 13 minutes again

The number from the original post that I think deserves a second look is the Effectiveness ROI: one DXI point equals 13 minutes per week per developer, from data on 40,000 developers. In 2025 that was a modest argument for investing in developer experience. In 2026 it is a much larger argument, because the thing most likely to move the Effectiveness score is how the agents are integrated, and that is a product decision. Whether the coding agent has access to the right context, whether its output lands in a review flow that engineers trust, whether the test suite is fast enough for an agent to iterate against: each of those is a point or several on the index, and each is a decision the product and platform teams make, not the individual engineer.

So the 13 minutes becomes the PM’s lever. If the organization has 400 engineers and agent integration is poorly done, costing, say, five DXI points, the arithmetic from the original post puts that at 65 minutes per engineer per week, which is more than 430 engineering hours weekly, spent on friction that a product decision could remove. I am using Tacho’s conversion and inventing nothing beyond the hypothetical headcount. The point is that the dimension executives found soft in 2025 is the one that now prices the quality of your agent rollout, and it does so in hours.

I wrote earlier this autumn about instrumenting a PM’s own workday the way one would instrument a product; the same instinct applies to the engineering scorecard, where the number that is easiest to collect is now the one that says the least.

What the authors got right without knowing why

Core 4 is dated January 2025, and its benchmarks predate agentic coding. Any reading of it in 2026 has to say so, and I would expect DX to publish revised benchmarks before long, because 6.6 PRs per engineer per week as a target is a sentence from another era. What has not aged is the architecture. Four dimensions in tension, one of them a volume measure that must never be read alone, was the right design for a world in which volume was hard to produce. It turns out to be an even better design for a world in which volume is trivial, because the tension is what stops the trivial number from being mistaken for the result.

I am not sure the authors would have chosen PRs per engineer if they had been writing in 2026. I am fairly sure they would have kept the other three, and I think a product manager who sits down with an engineering lead this quarter and says “show me Effectiveness, Quality and Impact first, and tell me what the Speed number is measuring before you tell me what it is” is using the scorecard exactly as it was meant to be used. The number on the dashboard that moved the most is the one that means the least. The scorecard was built to say so. It just took agents to make the lesson obvious.

Core 4 made PRs per engineer a health metric in January 2025, and agents just made it the most… was originally published in Let’s Code Future on Medium, where people are continuing the conversation by highlighting and responding to this story.

Between September 25 and October 1, 2026, the Claude Code changelog recorded four releases that together describe a new kind of control surface. Version 2.1.283 on September 25 added two managed-settings controls, availableModelsMatch and deniedModels, along with a gateway provider for AWS. Version 2.1.284 on September 28 made Claude Sonnet 5.5 the default Sonnet and put spend-limit tracking into the /usage command and the status line, with dollar figures of the form “$271.40 / $500.00.” Version 2.1.285 on September 29 added an allowedProviders managed setting and a switch to disable web fetch entirely. Version 2.1.287 on October 1 introduced Mods, which let plugins modify the tool’s deeper behavior. In the same window, GitHub’s Copilot added Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna and Grok 4.7 to its plans in a single week, put local sandboxing into public preview, and on October 1 put HydraFusion into research preview, a feature that lets a user “select HydraFusion in the model picker to choose models and workflows for your coding tasks automatically.”

I read these two changelogs as a single argument conducted by two companies, and the argument is about defaults. Anthropic shipped a way for an organization to say which models and which providers its engineers may use, with a dollar cap on top. GitHub shipped a way for a meta-model to pick among four vendors on the engineer’s behalf without the engineer choosing. Both are settings in a managed config. They point in opposite directions, and an engineering organization is going to have to choose one, or more likely choose where along the line between them it wants to sit. That choice used to be called platform strategy and it used to take a quarter of meetings. It is now a file, and the file has no owner yet.

The allow-list is a budget primitive wearing a security costume

Look at what Anthropic actually shipped and in what order. The model controls arrived first, on September 25. They let an administrator pattern-match which models are available and name which are denied. Three days later came the spend cap, visible as dollars against a limit in the status line. A day after that came the provider allow-list, which decides whether requests may go to Anthropic directly, through the AWS gateway, or through whatever other gateway the company has stood up. Taken together, the settings answer the questions that finance and security have been asking separately for a year: which models, through which pipe, up to how much, and who finds out when the limit is reached.

The temptation is to file all of this under governance, and the security framing is real. A deny list keeps an unvetted model out of a regulated codebase. A provider restriction keeps traffic inside a cloud account the company already audits. But the sequencing tells me the primary customer is the person who pays the bill. The spend cap in dollars is the most concrete thing in the changelog, and a model allow-list is the most direct lever on that number, because the price difference between tiers is the single largest variable in an agent’s running cost. Sonnet 5.5 became the default Sonnet on September 28 at $2 per million input tokens and $10 per million output. An organization that wants to hold its coding spend at a known figure now has a setting that says “Sonnet only” and a dial that says “$500,” and the two together are a budget, written as config.

I wrote in September that model choice had become a budget line per workflow. This is that budget line acquiring an enforcement mechanism, and the enforcement sits in the tool rather than in a spreadsheet someone checks monthly. Whoever edits that file is making the spend decision, whether or not their title says so.

HydraFusion is the opposite default, and it is also a budget decision

Now read GitHub’s month. In the week of September 21, Copilot added four models from three rival vendors in seven days. Opus 5.5 and GPT-6 Sol went to the Pro+, Max, Business and Enterprise plans; Luna and Grok 4.7 also reached Pro. On October 1 the monthly roundup for VS Code added Sonnet 5.5 and GPT-6.1 Sol to the picker, and alongside them HydraFusion, which removes the picker from the engineer’s hands. Select it and a model chooses the model.

That is a default in the other direction. Where Anthropic’s settings let an organization narrow the choice, HydraFusion widens it and then delegates it. The engineer does not decide which vendor serves the request, and under the current preview, neither does the administrator in any fine-grained way. A meta-model decides, per task, using criteria GitHub has not fully published. For a developer this is pleasant. For whoever owns the bill, it is a variable cost with a decision-maker who cannot be interviewed.

I do not think HydraFusion is wrong, and I want to be fair about why it exists. Choosing a model per task is tedious, most engineers choose badly or never change the default, and a router that picks a cheap model for a rename and an expensive one for a hard refactor would, on average, both improve results and cut cost. The question is who gets to see the routing policy and who gets to constrain it. GitHub’s answer so far is that enterprise-managed settings govern things like OpenTelemetry export of agent activity, which means you can watch what HydraFusion did after the fact. Anthropic’s answer is that you can forbid things in advance. Observability versus prohibition. Both are legitimate stances on the same config file, and a company can want both at once.

The tool argues with itself: Projects and the dollar cap

The part of the Claude Code month I find most telling is that two of its own features pull against each other. On September 17 Anthropic launched Claude Code Projects in beta, for Pro and Max subscribers on cloud sessions, expanding to Team and Enterprise. The company’s description: “Threads do the work, Claude directs it. Each Project has a coordinator sitting above those worker threads.” There is no separate price. Usage draws from the subscription, and users are warned that concurrent threads can reach limits faster.

Eleven days later the same tool got a status line that shows spend in dollars against a cap. So within two weeks a user received a feature designed to run several threads at once, drawing on the same allowance, and a gauge that shows how fast the allowance is going. I do not think this is a contradiction so much as an honest picture of where agentic tooling is in October 2026. The product wants to do more on your behalf, in parallel, without you watching. The buyer wants to know what that costs before it happens. The changelog shipped both desires in the same fortnight and left the reconciliation to the customer.

For a product manager inside an engineering organization, that reconciliation is the actual job. A coordinator agent that spawns worker threads is a multiplier on whatever model policy is in force. If the allow-list permits an expensive model and a Project fans out to five threads using it, the $500 cap is reached before lunch and the status line turns into a stop sign. If the allow-list restricts to a mid-tier model, the Project runs longer and the output is whatever that tier produces. Neither outcome is wrong. Both are consequences of a setting, and the setting was probably written by someone thinking about security rather than about fan-out.

Who owns the file

This is the question I think most organizations have not asked, and I want to work through the candidates honestly, because each has a claim.

The platform team has the strongest technical claim. It already owns the managed-settings distribution, understands the gateway options, and can test what a deny rule does to a workflow before rolling it out. It also has a bias: platform teams like uniformity, and the simplest file is one that permits a single model through a single provider. That is tidy and probably wrong for an organization whose tasks vary as much as code does.

Security has the clearest mandate for part of the file. Which providers may receive company code is a data-handling decision, and the allowedProviders setting is where that decision gets enforced. Security should write that line. It should probably not write the model lines, because a security team has no basis for deciding whether a refactoring task deserves Opus or Sonnet, and left to its own instincts it will deny by default and the engineers will route around it.

Finance owns the cap, obviously. The dollar figure in the status line is a finance number and finance should set it. Finance should not set the model list either, for the mirror reason: it will pick the cheapest tier for everything and the quality cost will show up as rework that never gets attributed back to the setting.

The engineering manager is the person who actually knows which tasks need which model, and who feels the quality tradeoff daily. That argues for giving the manager the model lines. The weakness is scale: a company with forty teams cannot have forty files, and the manager has the least time of anyone on this list to think about it.

My recommendation, for what it is worth, is a file with sections and section owners, which is boring and correct. Providers belong to security. The cap belongs to finance. The model match and deny lists belong to a small group that includes the platform team and at least two engineering managers from teams with different workloads, and they review it monthly against what the usage data shows. A PM should sit in that group, because the file determines the tooling the product team ships with, and because somebody has to be the person who notices that the tidy single-model policy is slowing the hard tasks down. The file should also be versioned and reviewed like code, with the deny of a model treated as a change that needs a reason in the commit.

Where the meta-model fits in a policy

The harder question is whether a company that writes an allow-list can also use something like HydraFusion, and I think the answer is yes with a constraint. A router that picks among permitted models is a sensible component. A router that picks among all models the vendor offers is a policy violation dressed as a convenience. The design that works is layered: the organization’s allow-list defines the set, and the router chooses within it. GitHub’s current preview does not make that layering explicit, as far as I can tell from the published notes, and I would want to see the routing constrained by managed settings before letting it loose on a regulated codebase.

The same logic applies to the other automation GitHub shipped this month. Scheduled Automations run agent tasks on a timer without a person present, and Agent merge resolves review feedback and failed checks on its own. Each of those is a consumer of whatever model policy is in force, running at times when no engineer is watching the status line. A spend cap matters more when the spender is a cron job.

There is also the sandboxing, which arrived in Copilot’s public preview the same month and which I will come back to in another post. For now the relevant point is that local sandboxing limits what an agent may touch, and the model allow-list limits what an agent may be. They are two halves of the same config file, and today they are owned by nobody in most organizations.

The platform decision was always a default

Platform decisions used to be visible because they were expensive. Choosing a cloud, choosing a database, choosing a language, choosing an identity provider: each was a procurement process with a slide deck and a signature, and the people in the room knew they were making a decision that would outlast them. The model and provider decision for coding agents has arrived as a config key, and config keys do not get slide decks. They get set by whoever installs the tool, with whatever default the vendor chose, and the default becomes the policy because nobody owns changing it.

Anthropic’s default, in the absence of a managed file, is that everything is permitted and the subscription is the only limit. GitHub’s default, with HydraFusion selected, is that a model chooses for you. Both are reasonable for an individual. Neither is a policy for a company, and a company that does not write one has adopted one of them anyway.

I am not sure which direction most organizations will settle on, and I suspect it will track their size. Small teams will take the router and the convenience, and discover their bill in arrears. Large ones will write deny lists and discover, slowly, that the hard tasks are being done on the wrong model because the list was written by someone who never ran one. The organizations that get it right will be the ones that treat the file as a product with an owner and a review cycle, and that read the status line as feedback about the policy rather than as a warning to the engineer. The engineer did not pick the model. The file did.

Claude Code shipped a model allow-list the same month GitHub let a meta-model pick the vendor, and… was originally published in Let’s Code Future on Medium, where people are continuing the conversation by highlighting and responding to this story.