Forward Deployed Engineering

01 The deployment gap

A vendor sells a capability. A customer needs an outcome. Between those two things sit five boundaries, and most implementations fail at one of them rather than at the technology itself.

Nothing about that is new. What has changed is the volume and the stakes: enterprises are now buying systems whose behaviour is probabilistic, whose integration surface reaches into their most sensitive data, and whose value depends entirely on people changing how they work. AWS announced a billion-dollar commitment to a dedicated forward deployed engineering organization in June 2026 on exactly this reasoning.^[1] Accenture announced a Microsoft-focused forward deployed engineering practice three months earlier, on its own account.^[5] OpenAI and Anthropic each spun delivery into a separate services venture rather than scaling it inside the lab.^[6][7]

Select a boundary to see what actually goes wrong there.

Each of these is solvable. None of them is solvable by documentation, and only the first is reliably solvable by a pre-sales architect who leaves after the design review. That is the argument for forward deployment, and it is worth stating in its weakest defensible form rather than its strongest: some problems sit in the seams between systems and teams, and the seams are where nobody has authority to change code.

02 What makes engineering “forward deployed”

Forward deployed engineering is an operating model, not an architecture. The architecture on this page is a synthesized reference design for supporting that model. There is no canonical forward deployed architecture, and I have found no standards body that defines one.

Five properties separate it from adjacent ways of working. An engagement missing several of them is doing something else, whatever it is called, and the label then obscures rather than clarifies what is being bought. Marty Cagan’s argument for the model is that it accelerates product discovery, and that it “applies much more broadly than just in the most challenging product situations” — worth weighing as advocacy from a product-management perspective rather than as evidence.^[11]

The label is contested, and that is worth knowing

The term expanded very quickly. Job postings for forward deployed roles were reported by the Financial Times to have risen more than 800% between January and September 2025, a figure repeated widely although the underlying dataset is not identified in any source I could find.^[19] That growth has pulled in work that does not match the definition. Constellation Research’s Ray Wang put it bluntly: “Some of these FDEs don’t necessarily fit the definition and are glorified sales and customer success people.”^[16] Gergely Orosz, reading a major cloud vendor’s posting for the role, translated it as “you are a contractor who codes at a customer’s office”.^[13] Sierra’s own account concedes that the term “can mean so many things” that it risks becoming meaningless.^[20] Even the encyclopaedia entry for the role is thin, resting largely on vendor self-description.^[18]

The vendors are not consistent either. AWS positions its practice explicitly against traditional consulting.^[1] Databricks files its AI forward deployed engineering team under Professional Services Operations and describes the work as “professional services engagements”.^[8] Vercel’s posting says “this is not a traditional consulting role” while reporting the role to a Director of Professional Services.^[9] None of that makes the model illegitimate. It does mean that “we use forward deployed engineers” carries almost no information on its own, and that an enterprise buying the model should ask what specifically it is buying.

03 FDE and adjacent roles

The boundaries between these roles vary by company. What follows is a comparison of common operating patterns, not a set of formal industry definitions, and any given organization will place at least one of them differently.

04 Forward-deployed reference architecture

Six runtime layers with two concerns that cut across all of them. This is a reference design I assembled to reason about the model, not a description of any vendor’s product. Named technologies are examples of what can occupy a slot, never requirements.

Select a layer for its purpose, the split of responsibility between vendor and customer, what tends to go wrong there, and example technologies.

05 One operating model, different deployment boundaries

The operating model barely changes across these five. What changes is where the trust boundary falls, and every consequential decision on the page follows from that: how software is updated, how the engineer reaches the system, whether telemetry ever arrives, and who holds the credentials.

06 Decisions that matter

These are the ten decisions I have found determine whether a forward deployed engagement stays maintainable. Each has a genuine case on both sides; the failure is not choosing wrong, it is choosing implicitly and discovering the choice two years later during an upgrade.

07 Engagement lifecycle

Eleven stages. The first one is the one most organizations skip, and skipping it is why the model gets a reputation for being expensive.

08 The feedback loop

This is the part of the model that determines whether it is a business or a service line with unusually expensive staff.

The model scales only when field learning improves the platform. If every engagement stays bespoke, forward deployment is custom consulting carrying a software company’s valuation. F-Prime Capital, writing from an investor’s perspective, proposes a working threshold: if more than 30–40% of deployments require significant forward deployed effort, the problem has stopped being go-to-market and become product design.^[15] That figure is a practitioner heuristic rather than a measured finding, and I would treat it as a prompt to instrument rather than a number to manage to. The underlying claim is harder to argue with: “if every deal requires bespoke engineering, you don’t have a product; you have a consultancy with a logo”.^[15]

There is a serious counter-position. Andreessen Horowitz argues that optimizing for gross margin percentage is the wrong objective early, and points at ServiceNow and Workday, both of which entered public markets in the fifties and low sixties and reached the mid-to-high seventies years later.^[17] Both parties are investors and both have a position to talk. The reconciliation I find defensible is narrow: services-heavy delivery is a legitimate investment when it is buying a repeatable capability, and it is a permanent cost when it is buying a customer. The instrumentation that tells you which one is happening is in Measuring outcomes, and most organizations running this model do not have it.

09 Productization economics

Every forward deployed engagement produces code that should not stay where it was written. The discipline is knowing which code that is, and having somewhere for it to go that is not the core product.

The promotion questions

Before customer-specific work is promoted toward the core, these nine questions decide whether it should be. A “no” to the last one is disqualifying regardless of the others.

• How many customers actually need this, as opposed to how many might?
• Is the requirement domain-specific, or does it encode one organization’s internal process?
• Does it expose a platform primitive that is missing, or does it work around one that exists?
• What permanent complexity does supporting it add, and to whom?
• Who owns its lifecycle after the engagement ends, by name?
• Can it be tested independently of the deployment it came from?
• Can it be versioned, deprecated and removed?
• Can it live outside the core behind an extension contract instead?
• Does moving it into the core reduce total delivery cost across the portfolio, rather than only in the next engagement?

The customization debt register

Every customization that is not immediately promoted or retired goes into a register. This is the artifact that makes upgrade planning possible, and its absence is why organizations discover during a major version upgrade that they cannot enumerate what they have built.

10 When the product is AI

Forward deployment of a deterministic application is a hard integration problem. Forward deployment of an AI system is that plus a component whose behaviour is part of the production system and changes when the vendor ships a model. Everything below exists because of that difference.

Two claims are worth stating before the diagram, because architectures in this space are frequently built on their opposites. Model capability is not system reliability: a model that answers well in a demo is evidence about the demo. And benchmark performance does not predict workflow performance — a randomised controlled trial published by METR in 2025 found experienced open-source developers took 19% longer to complete real issues when allowed to use AI tooling, while predicting a 24% speedup beforehand and still believing they had been 20% faster afterwards.^[69] That result is a snapshot of early-2025 tooling on a specific kind of work and should not be generalized further than that. What generalizes is the shape of the error: the people closest to the system were confidently wrong about its effect, in the same direction, and only measurement caught it.

Select a stage of the production path for the engineering concerns that attach to it.

Prompt injection is a design constraint, not a pending fix

An AI system that reads untrusted content and can take actions has an attacker-controlled input path into its instructions. This is not a solved problem and no credible source claims it is. OWASP’s LLM Top 10 states it directly: “given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection”.^[42] OpenAI’s Chief Information Security Officer described it in October 2025 as “a frontier, unsolved security problem”.^[47] Anthropic, publishing a defence that reduced attack success to 1% against an adaptive attacker, wrote that this “still represents meaningful risk” and that they were sharing the results “to demonstrate progress, not to claim the problem is solved”.^[48] The attack class was formally characterized in 2023 and has not been closed since.^[49] NIST’s adversarial machine learning taxonomy treats it as an open problem area and warns that “many of these mitigations may themselves be vulnerable to new discoveries and evolutions in attacker techniques”.^[30]

The architectural consequence is specific. Split your controls into two sets and be honest about which is which. Input filtering, provenance framing and content classification reduce the rate at which injection succeeds; they are classifiers operating on adversarial natural language and cannot carry a safety case. Authorization enforced in the downstream system, identity and audience binding, egress control and approval bound to a specific payload do not care whether the model was fooled. Put the safety case on the second set and budget the first as defence in depth.

Tool integration and MCP

Where a system reaches tools through the Model Context Protocol or an equivalent, the protocol specification itself is unusually clear about what it does not do. Revision 2026-07-28 states that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server”, and that “while MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD” build the controls themselves.^[50] It also carries hard normative requirements that early integrations routinely violated, including “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server” and “MCP servers MUST NOT treat possession of a state handle as authentication”.^[50]

The risk is not theoretical. CVE-2025-49596 in the MCP Inspector developer tool carried a CVSS v4.0 base score of 9.4 for unauthenticated remote code execution caused by a missing authentication step between the inspector client and its proxy.^[51] A forward deployed engagement that connects an agent to customer systems inherits every one of these decisions. The minimum set worth insisting on: an inventory of which servers are trusted and who approved them, per-target token exchange with an explicit audience rather than passthrough, tool permissions scoped to the single call, secrets held outside the tool’s reach, validation of the action rather than of the intent behind it, transaction and rate limits, and an audit record that survives the compromise of the thing being audited.

OWASP published a Top 10 for Agentic Applications in December 2025 with its own identifier series — ASI01 Agent Goal Hijack through ASI10 Rogue Agents — which is a better fit for this material than the LLM list alone.^[44] There is also an OWASP MCP Top 10, but it is an Incubator project at version 0.1 and should not be cited with the weight of a flagship document.^[45]

11 GraphRAG: useful grounding, not a guarantee

A semantic layer over enterprise data is a good idea for reasons that have nothing to do with hallucination. It is also routinely sold on a claim that the measurements do not support, and the correction matters because the claim changes what controls people think they need.

What a graph or ontology genuinely provides

• Retrieval constrained to entities and relationships that exist, which removes a class of fabricated references.
• Provenance that points at identified nodes and edges rather than at a text chunk, which is the strongest governance argument for the pattern.
• A structured place to enforce authorization, including permissions inherited through relationships rather than restated per object.
• Better handling of relationship-heavy questions than passage retrieval, which is what graph structures are actually for.
• Normalization across heterogeneous sources, with the trade-off stated: normalizing an EC2 instance and an Azure VM into one concept discards the provider-specific attributes that some questions need.
• An execution step that is genuinely deterministic. Given a fixed query and a fixed graph state, the result is reproducible and auditable.

What it does not provide

The pipeline has three stages and only the middle one is deterministic. Translating a question into a query is a language-model operation. Turning the returned rows back into prose is a language-model operation. Both are probabilistic, and constraining the output to a valid schema does not change that — it changes the failure mode from fabricated prose to a query that is syntactically valid, schema-conformant, and answers a different question than the one asked, returning a clean-looking result set with no signal that anything went wrong.

The numbers

These are the measurements that made me rewrite this section rather than soften it.

The 0.916 against 0.189 pair is the one to keep. A schema checker passing more than nine in ten generated queries while fewer than one in five return the right answer is the arithmetic of why schema verification is not error elimination. It catches references to labels and properties that do not exist, which are the cheapest errors. The expensive ones use the right vocabulary to ask the wrong question.

Entity resolution deserves separate attention because a knowledge graph inherits every merge error and every missed merge as a fact. The benchmark drop from 89.0 to 64.6 F1 falls precisely on the case an enterprise graph meets every time a new supplier, customer or asset appears.^[66] That is not an argument against building the graph. It is an argument for treating it as a maintained asset with a measured resolution quality rather than as ground truth.

Nor does an LLM verification step close the gap on its own. Google DeepMind’s ICLR 2024 result is that language models “struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction”.^[65] A schema is external feedback about schema errors, which is why that check works. It is not external feedback about whether the query captured the user’s intent.

Mitigations that actually apply

12 Zero Trust is broader than data access

Access control at the semantic layer is a real Zero Trust control and a good one. It is not Zero Trust, and the difference is not pedantry — it decides which controls a design review will find missing.

NIST SP 800-207 defines zero trust architecture as “an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies”, and states plainly that “ZT is not a single architecture but a set of guiding principles” and that transitioning to it “cannot simply be accomplished with a wholesale replacement of technology”.^[21] The document lists seven tenets. Role- and attribute-based authorization enforced at a data or ontology layer contributes strongly to three of them — per-session access decisions, dynamic policy incorporating identity and asset state, and authorization strictly enforced before access is allowed. It contributes nothing on its own to the other four: treating all data sources and computing services as resources, securing all communication regardless of network location, continuously measuring the integrity and security posture of every asset, and collecting state telemetry to improve posture.

The practical consequence for a forward deployed engagement is that the security conversation cannot be delegated to whoever owns the data model. Workload identity, secrets custody, supply chain provenance and the telemetry that makes continuous verification possible all sit with different teams, usually on the customer side, and all of them need to be in the architecture before the first production deployment rather than after the first assessment.

13 The access boundary

This is the diagram I would put in front of a customer security team first, because it answers the question they are actually asking: what can your engineer do in my production environment, and how would I know?

Two things make this diagram hold up in practice rather than only in a document. Audit custody sits outside the administrative domain of the people being audited, so the evidence survives the case where the vendor account is the thing that was compromised. And access is requested through the customer’s own workflow rather than the vendor’s, which is the difference between the customer being able to revoke access and the customer being told that access was revoked.

Everest Group makes the sharper version of the point, and it is worth taking seriously precisely because it comes from outside the enthusiasm: introducing forward deployed engineers into an environment with mature change control “can bypass these safeguards”, and “real-time changes to production code create security risks and the potential for significant failures”.^[14] The correct response is not to argue with that. It is to design the engagement so that the claim is false in your case, and to be able to show how.

14 Where the model fails

Twelve failure modes. Each has symptoms you can look for, a root cause that is usually structural rather than individual, and an owner — because a mitigation with no owner is a hope.

15 Reference scenarios

16 When should an organization use forward deployment?

Up to nine questions, depending on the path. The honest answer for most problems is one of the six alternatives, and an organization that reaches “forward deployed engineering” for everything has stopped using the question as a filter.

The alternatives are not lesser outcomes. Everest Group’s framing is that the question is “not whether they are good or bad” but “where they fit”, and that in environments with mature change control forward deployed engineers “are not only unnecessary… but they can be actively harmful”.^[14] Choosing partner delivery for a repeatable implementation is a better decision than assigning the scarcest engineers you have to work a certified third party could do without them.

17 Operating-model maturity

Six levels. Most organizations running this model are at level 0 or 1 and describe themselves as being at level 3, which is easy to test: the artifacts of the higher level do not exist and can be asked for.

18 Who owns what

An example operating model, not a universal one. Every organization I have looked at places at least two of these differently, and the value of writing it down is the argument it starts rather than the grid it produces.

Three placements in this grid are deliberate and are where most disagreement lands. Production deployment and incident response are accountable to customer operations rather than to the vendor engineer, which is the structural expression of the access-boundary argument: the party accountable for production is the party that controls production. And evaluation is accountable to the engineer who built the AI component but responsible to the customer product owner, because the labels that define correct behaviour are the customer’s knowledge and cannot be delegated to whoever wrote the code.

19 Prototype is not production

A working prototype is evidence that a hypothesis held under the conditions you tested. It is not a production system, and the gap between them is a defined body of work rather than a tidying-up exercise. This is the checklist I would put a named approver behind.

20 Measuring outcomes without rewarding heroics

No benchmark values appear below. Every organization’s baseline differs and a published target would be a number I invented. What each metric is for is stated instead, because a metric whose purpose is unstated gets optimized in whatever direction is easiest.

21 Standards and governance alignment

Versions below were checked against primary sources on 9 August 2026. Several changed within the preceding twelve months in ways that invalidate widely circulated guidance, and those are marked. Filter to the frameworks that apply to your boundary rather than reading all of them.

22 Architecture versus compliance, worked once

The distinction the previous section rests on is easier to see in a single example than in an argument. Privileged access is the right one to use, because it is the control a forward deployed engagement is most likely to weaken and the one an assessor will look at first.

Each row is a different activity performed by different people. The architecture supplies the second row and makes the fourth row possible. It cannot supply the third, the fifth or the sixth. NIST puts the responsibility explicitly on the organization: “organizations have the responsibility to select the appropriate security and privacy controls, to implement the controls correctly, and to demonstrate the effectiveness of the controls in satisfying security and privacy requirements”.^[24] Assessment is defined as determining “if the controls are implemented correctly, operating as intended, and producing the desired outcomes”.^[25] None of those verbs belongs to a design.

“Security and privacy control assessments are not about checklists, simple pass/fail results, or generating paperwork.”

NIST SP 800-53A Rev. 5^[26]

23 What a disciplined engagement produces

Nineteen artifacts. None of them are downloadable from this page, because I have not written them for a real engagement and publishing templates I have not used would be filler. What follows is what each one is for and why its absence hurts.

24 What the model teaches

Eight conclusions I would defend, written as claims rather than as principles because principles are harder to disagree with and disagreement is the useful part.

1. Proximity to the customer is not a substitute for engineering discipline, and is often used as one. The argument that tests, reviews and documentation can wait because the customer needs it Friday is the same argument every quarter, and it compounds.
2. The hardest problems sit between systems and between teams, not inside an API. That is why the role exists at all, and why staffing it with someone who cannot change code produces a well-documented list of things that cannot be done.
3. A successful prototype is evidence that a hypothesis held, not evidence that a system exists. Treating the two as the same thing is how a project comes to overrun its estimate by a multiple rather than a margin.
4. The model scales only when repeated fieldwork becomes reusable platform capability. Everything else in the operating model is downstream of whether that loop is closed and instrumented. Nobody has ever closed it by intending to.
5. Access should narrow as a deployment matures. If the vendor account still holds the permissions it needed during implementation, the engagement has a security posture that was set by delivery pressure two years ago.
6. AI deployment requires continuous evaluation because model behaviour is part of the production system. A component whose vendor can change its behaviour without your release cycle is a dependency with no change control, and evaluation is the only thing standing in for it.
7. A semantic layer improves retrieval, provenance and policy enforcement, and does not eliminate probabilistic failure. The measurements are unambiguous and they are worse than the diagrams imply. Design for the wrong-but-plausible answer, because it will occur and it will look correct.
8. The strongest organizations optimize two things at once: the customer outcome, and the rate at which field learning improves the product. Optimize only the first and you have built an excellent consultancy. Optimize only the second and you have built a platform nobody has deployed.

25 Questions

The role

Scope and economics

Security and access

AI systems

Governance and organization

26 Corrections

This project began from four research documents on forward deployed engineering and enterprise ontology. Parts of them are good: the deployment-topology analysis, the challenge and mitigation pairs, the lifecycle structure and the governance discussion are all sound and are reflected throughout this page. Parts did not survive verification. Those are listed here rather than quietly dropped, because a reader has no way to tell checked work from written work unless the checking is shown.

27 Sources and method

This project combines analysis of publicly documented forward deployed operating models, architecture and security standards, peer-reviewed research on retrieval and query generation, and current AI security guidance. The architecture diagrams are reference designs rather than representations of any vendor implementation. The four deployment scenarios are composites and are labelled as such. No client, deployment, customer or measured result is described anywhere.

Method, briefly. I read the four source documents in full and built a claim-by-claim ledger classifying each substantive statement as publicly verifiable, source-derived, an architectural recommendation, a composite scenario, or an interpretation — then verified the first category against primary sources and corrected or removed what failed. Every version number, publication date, framework identifier and quoted normative sentence below was checked against the issuing body rather than written from memory, on 9 August 2026. Vendor material is labelled as vendor-reported throughout and is never presented as independent verification. Where two primary sources conflict, both are noted. Where I could not verify something, it is not asserted.

One structural caution about the subject itself. Several of the frameworks cited here changed within the last twelve months in ways that invalidate guidance still in wide circulation — among them the OWASP LLM identifiers renumbered in August 2026, a new OWASP agentic list in December 2025, SLSA v1.1 retired in November 2025, the OpenSSF baseline reissued in February 2026, FedRAMP restructured through 20x, and CMMC Phase II suspended in July 2026. Parts of this page will be wrong within a year. That is a property of the material. The fix is a re-verification cadence rather than a review date.

Forward deployed engineering: primary company sources

1. Amazon Web Services, “AWS invests $1 billion to embed AI forward deployed engineers with customers”, 30 June 2026. aboutamazon.com/news/aws/aws-1-billion-forward-deployed-ai-engineers — vendor announcement. Accessed 9 Aug 2026.
2. Palantir Technologies, Forward Deployed Software Engineer role descriptions, official applicant tracking system. jobs.lever.co/palantir — vendor self-description. Accessed 9 Aug 2026.
3. OpenAI, Forward Deployed Engineer and Technical Deployment Lead role descriptions. openai.com/careers — vendor self-description. Accessed 9 Aug 2026.
4. Anthropic, Forward Deployed Engineer, Applied AI (Federal Civilian) role description. job-boards.greenhouse.io/anthropic — vendor self-description. Accessed 9 Aug 2026.
5. Accenture, “Accenture launches Microsoft Forward Deployed Engineering practice”, 18 March 2026. newsroom.accenture.com — vendor announcement; no financial figure disclosed.
6. OpenAI, “OpenAI launches the Deployment Company”, 11 May 2026. openai.com/index/openai-launches-the-deployment-company — vendor announcement.
7. Anthropic, enterprise AI services company announcement, 4 May 2026, subsequently branded July 2026. anthropic.com/news/enterprise-ai-services-company — vendor announcement. Note it uses “Applied AI engineers” rather than the forward deployed label.
8. Databricks, AI Engineer — FDE role description, listed under Professional Services Operations. databricks.com/company/careers — vendor self-description. Accessed 9 Aug 2026.
9. Vercel, Forward-Deployed Engineer role description. vercel.com/careers — vendor self-description. Accessed 9 Aug 2026.
10. Salesforce, “Forward deployed engineer”, company blog, 19 November 2025. salesforce.com/blog/forward-deployed-engineer — vendor-reported; the thousand-engineer figure is a stated commitment.

Independent and analyst commentary

1. Marty Cagan, “Forward Deployed Engineers”, Silicon Valley Product Group, 17 September 2025. svpg.com/forward-deployed-engineers — independent practitioner advocacy, not empirical research.
2. Jina Yoon, “Forward deployed engineer”, PostHog, 11 February 2026. posthog.com/blog/forward-deployed-engineer — company blog. The on-site and infrastructure-access passage describes the industry pattern; PostHog’s own engineer is fully remote and asynchronous.
3. Gergely Orosz, “Forward deployed engineers” (12 August 2025) and “The Pulse: forward deployed engineering heats up again” (24 May 2026), The Pragmatic Engineer. newsletter.pragmaticengineer.com — independent journalism. Contains no economic data; do not cite for unit economics.
4. Peter Bendor-Samuel, “When are forward deployed engineers essential, and when are they not?”, Forbes / Everest Group, 30 April 2026. forbes.com — analyst-firm commentary. Contains no cost or margin data.
5. Rocio Wu, “The uncomfortable truth about FDEs”, F-Prime Capital, 6 February 2026. fprimecapital.com/blog/the-uncomfortable-truth-about-fdes — venture-capital commentary. The 30–40% threshold is a stated heuristic, not a measured finding.
6. Larry Dignan, “AWS launches forward deployed engineering unit”, Constellation Research, 30 June 2026. constellationr.com — analyst commentary, quoting R “Ray” Wang.
7. Joe Schmidt, “Trading margin for moat”, Andreessen Horowitz, 4 June 2025. a16z.com/services-led-growth — venture-capital advocacy; a16z invests in companies using this model.
8. “Forward Deployed Engineer”, Wikipedia. en.wikipedia.org/wiki/Forward_Deployed_Engineer — used only as a signpost to primary sources. Thinly sourced; several of its comparisons are editorial synthesis rather than sourced company statements.
9. Financial Times reporting on growth in forward deployed engineering job postings, as relayed by PYMNTS (10 March 2026) and Fast Company (5 November 2025). The underlying dataset is not identified in any source located; the figure counts postings rather than filled roles.
10. Richard MacManus, interview coverage including Sierra on the ambiguity of the term, Latent.Space, 1 July 2026. latent.space — independent technology journalism.

Standards, government and regulatory

1. NIST SP 800-207, Zero Trust Architecture, August 2020. csrc.nist.gov/pubs/sp/800/207/final — final, not superseded.
2. NIST SP 1800-35, Implementing a Zero Trust Architecture, NCCoE, final 10 June 2025. csrc.nist.gov/pubs/sp/1800/35/final — the earlier lettered draft volumes are withdrawn.
3. NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, 26 February 2024. csrc.nist.gov/pubs/cswp/29 — final.
4. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, control catalog Release 5.2.0, 27 August 2025. csrc.nist.gov/pubs/sp/800/53/r5/upd1/final — cite the release as well as the revision.
5. NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations. nvlpubs.nist.gov — source of the assessment and authorization language quoted in section 22.
6. NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls. nvlpubs.nist.gov
7. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 26 January 2023. nist.gov/itl/ai-risk-management-framework — final; NIST states a revision is in progress. No public draft had been issued as of 9 August 2026.
8. The White House, Winning the Race: America’s AI Action Plan, July 2025. whitehouse.gov — directs the AI RMF revision; cited as the reason the framework is under revision.
9. NIST AI 600-1, AI RMF: Generative Artificial Intelligence Profile, 26 July 2024. nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf — source of the “confabulation” terminology.
10. NIST AI 100-2e2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, March 2025. nvlpubs.nist.gov — treats indirect prompt injection as an open problem area.
11. ISO/IEC 27001:2022 including Amendment 1:2024 (climate action changes). iso.org/standard/27001 — transition from the 2013 edition closed in October 2025.
12. ISO/IEC 42001:2023, Artificial intelligence — Management system; and ISO/IEC 42006:2025, requirements for certification bodies. iso.org/standard/42001 · iso.org/standard/42006
13. AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus — 2022). aicpa-cima.com — SOC 2 is an attestation examination, not a certification.
14. Center for Internet Security, CIS Critical Security Controls v8.1, 25 June 2024. cisecurity.org/controls/v8-1
15. SLSA v1.2 specification, approved 24 November 2025. slsa.dev/spec/v1.2 — v1.1 is explicitly marked retired.
16. OpenSSF Open Source Project Security Baseline, release 2026-02-19. baseline.openssf.org
17. HHS, HIPAA Security Rule and the proposed rule to strengthen cybersecurity of ePHI (RIN 0945-AA22), published 6 January 2025. hhs.gov · federalregister.gov · reginfo.gov — not finalized; now listed under long-term actions. The existing Security Rule at 45 CFR 164 Subpart C governs.
18. PCI Security Standards Council, PCI DSS v4.0.1, June 2024. pcisecuritystandards.org — the previously future-dated v4.x requirements have been in force since 31 March 2025.
19. FedRAMP 20x programme and Consolidated Rules for 2026. fedramp.gov/20x — Phase 3 active from April 2026; terminology and artifacts renamed.
20. US Department of Defense CIO, CMMC programme status including the suspension of Phase II requirements announced 13 July 2026; DFARS Case 2019-D041 final rule effective 10 November 2025. dodcio.defense.gov/CMMC · federalregister.gov
21. NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, 14 May 2024. csrc.nist.gov/pubs/sp/800/171/r3/final — note that CMMC Level 2 is still assessed against Rev. 2.

AI and application security guidance

1. OWASP, LLM01 Prompt Injection, OWASP Top 10 for LLM Applications. owasp.org — source of the statement that fool-proof prevention is unclear.
2. OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026, August 2026. genai.owasp.org — identifiers renumbered from the 2025 edition; Excessive Agency is now third. OWASP’s own legacy page still displays 2025 identifiers.
3. OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications, December 2025 (ASI01–ASI10). genai.owasp.org
4. OWASP MCP Top 10. owasp.org/www-project-mcp-top-10 — Incubator project at v0.1 beta; cite with less weight than a flagship document.
5. MITRE ATLAS, data release v2026.05, May 2026. atlas.mitre.org · github.com/mitre-atlas — continuously updated; techniques now tagged by platform including agentic AI.
6. Dane Stuckey, Chief Information Security Officer, OpenAI, public statement on agent-mode security, 21 October 2025. Vendor statement — “prompt injection remains a frontier, unsolved security problem”.
7. Anthropic, “Prompt injection defenses”, 24 November 2025. anthropic.com/research/prompt-injection-defenses — vendor-reported; states a 1% attack success rate “still represents meaningful risk”.
8. Greshake, Abdelnabi, Mishra, Endres, Holz & Fritz, “Not what you’ve signed up for: compromising real-world LLM-integrated applications with indirect prompt injection”, ACM AISec 2023, arXiv:2302.12173. The canonical citation for the indirect prompt injection class.
9. Model Context Protocol specification, revision 2026-07-28, including Security Best Practices. modelcontextprotocol.io/specification — source of the quoted normative requirements.
10. CVE-2025-49596, MCP Inspector unauthenticated remote code execution, CVSS v4.0 base score 9.4, published 13 June 2025. nvd.nist.gov/vuln/detail/CVE-2025-49596

Research

1. Palantir, Ontology documentation and core concepts. palantir.com/docs/foundry/ontology — vendor documentation; no independent technical evaluation located.
2. Palantir, “Reducing hallucinations with the Ontology in Palantir AIP”, 8 July 2024. Vendor engineering blog. Note the verb: reducing, paired with human oversight.
3. Edge, Trinh, Cheng, Bradley, Chao, Mody, Truitt, Metropolitansky, Ness & Larson, “From local to global: a Graph RAG approach to query-focused summarization”, arXiv:2404.16130. Microsoft Research. Headline result concerns comprehensiveness and diversity, evaluated by preference judgement, not factual accuracy.
4. Microsoft, GraphRAG responsible AI transparency documentation. github.com/microsoft/graphrag — states that expert human verification of answers is needed and that the system is designed for trusted users.
5. Chauhan, Raj, Mujumdar, Saha & Jain, “Mind the query”, EMNLP 2025 Industry Track. aclanthology.org — peer-reviewed; 76.75% execution accuracy overall for the strongest model tested, 49.93% on complex aggregation.
6. Ranganath & Raghavendra, “PIPE-Cypher”, arXiv:2606.08481, June 2026. Preprint, not peer-reviewed. Reports 0.916 schema validity against 0.189 exact execution accuracy.
7. Shen, Wan et al., “Understanding, detecting and repairing real-world in-context-learning-based text-to-SQL errors”, PACM SE (FSE), arXiv:2501.09310. Peer-reviewed; semantic errors account for 36.1% of errors on one benchmark.
8. BIRD text-to-SQL benchmark leaderboard. bird-bench.github.io — accessed 9 Aug 2026; human baseline 92.96% execution accuracy.
9. Niu et al., “RAGTruth: a hallucination corpus for developing trustworthy retrieval-augmented language models”, ACL 2024. aclanthology.org — peer-reviewed.
10. Jacovi et al., “The FACTS Grounding leaderboard”, arXiv:2501.03200. Google DeepMind — vendor-reported research.
11. Joren, Zhang, Ferng, Juan, Taly & Rashtchian, “Sufficient context: a new lens on retrieval augmented generation systems”, ICLR 2025, arXiv:2411.06037. Peer-reviewed.
12. Xu, Jain & Kankanhalli, “Hallucination is inevitable: an innate limitation of large language models”, arXiv:2401.11817. Preprint, widely cited and contested.
13. Kalai, Nachum, Vempala & Zhang, “Why language models hallucinate”, arXiv:2509.04664; OpenAI, 5 September 2025. Vendor-reported. Argues confident hallucination is reducible through abstention while accuracy never reaches 100%.
14. Huang, Chen, Mishra, Zheng, Yu, Song & Zhou, “Large language models cannot self-correct reasoning yet”, ICLR 2024, arXiv:2310.01798. Google DeepMind; peer-reviewed.
15. Peeters, Bizer et al., “WDC Products: a multi-dimensional entity matching benchmark”, EDBT 2024, arXiv:2301.09521. Peer-reviewed; 89.04 F1 on seen entities against 64.56 on unseen.
16. Agrawal, Kumarage, Alghamdi & Liu, “Can knowledge graphs reduce hallucinations in LLMs? A survey”, NAACL 2024, arXiv:2311.07914. Peer-reviewed; frames the contribution as mitigation.
17. Ozsoy, “Enhancing Text2Cypher with schema filtering”, arXiv:2505.05118. Neo4j — vendor-reported research; benefit was not uniform across models.
18. METR, “Measuring the impact of early-2025 AI on experienced open-source developer productivity”, 10 July 2025, arXiv:2507.09089. Randomised controlled trial, 16 developers, 246 issues. A snapshot of early-2025 tooling on a specific kind of work.
19. Zhu, Jin, Pruksachatkun et al., “Establishing best practices for building rigorous agentic benchmarks”, arXiv:2507.02825. Preprint.
20. Liang, Bommasani, Lee et al., “Holistic evaluation of language models (HELM)”, TMLR 2023, arXiv:2211.09110. Peer-reviewed; seven evaluation axes.
21. Ong, Almahairi, Wu, Chiang, Wu, Gonzalez, Kadous & Stoica, “RouteLLM: learning to route LLMs with preference data”, ICLR 2025, arXiv:2406.18665. Peer-reviewed; reported savings vary by an order of magnitude across benchmarks.
22. Yan, Bischof, Frye, Husain, Liu & Shankar, “What we learned from a year of building with LLMs”, O’Reilly Radar, 28 May 2024. Practitioner synthesis, vendor-neutral.
23. He, “Defeating nondeterminism in LLM inference”, Thinking Machines Lab, 10 September 2025. Vendor-reported but reproducible; 1,000 completions at temperature zero produced 80 unique outputs before batch-invariant kernels were applied.
24. Turan, “Oversight has a capacity: calibrating agent guards to a subjective, fatiguing human”, arXiv:2606.08919, June 2026. Single-author preprint, not peer-reviewed. Cited for direction, not for its specific figures.
25. Parasuraman & Riley, “Humans and automation: use, misuse, disuse, abuse”, Human Factors 39(2), 1997. The canonical source for automation misuse and complacency; cited for the concept.