Guardrails & the control set

Which controls exist, which are actually switched on, and what they cost to run.

47documents on this topic
28organizations represented
3issues named
12sourced citations
0sourced statistics

The state of it

One of 6 topics within Security & threat model.

The control taxonomies for this are free, public and good. That is the first thing to say, because a great deal of paid material exists to restate them. The standards bodies publish a risk framework and a ranked list of application-layer risks; neither costs anything and both are better maintained than any private copy.

So the useful question is not what are the controls. It is which of them are switched on, what they cost to run, and what was turned off for convenience.

That last one is not hypothetical. The most instructive account in this band is a lab describing its own evaluation, run deliberately without the production classifiers that normally block high-risk activity, in order to measure what the model could do unconstrained. That is a defensible research choice, clearly stated. It is also an exact description of the ordinary enterprise failure: a control that exists, is understood, and is off in the environment where the work is happening.

Guardrails also have a running cost that nobody budgets. Filtering, validation and classification add latency and inference spend to every call, which is precisely the pressure that gets them relaxed in the environment where speed matters.

The issues, by agreement

How many independent organizations name each issue as a problem. An issue is only as real as the number of separate publishers that identify it, so the count is the ranking. Bars are organizations, not documents. Where the count reads ours, no publisher here states the issue and the analysis is our own.

Who takes which position

The chart above counts positions; this shows whose they are. Read down a column for what one organization holds across the whole topic, and across a row for who lines up on one issue. Where a cell carries more than one position, the strongest is shown and the rest are in the tooltip.

Ddisputes it Qqualifies it Nnames it as a problem Pproposes a fix
Guardrails & the control set: 3 issues against the 8 organizations cited on them. The number under each name is how many of these issues it is cited on.
Issue AWS · 2 Anthropic · 2 CISA · 1 Cloud Security Alliance · 1 FS-ISAC · 1 NIST · 1 OpenAI · 1 Palo Alto Networks · 1
The agent is only as safe as the tools it may call, and those were not reviewed P P N Q P · · N
The control is understood, documented, and switched off where the work happens Q N · · · · N ·
Guardrails have a per-call cost that no business case carries · · · · · P · ·

A dot means this organization is not cited on that issue. It does not mean they are silent on it: an organization is cited where its document takes a position we could locate, and the absence of a citation is the absence of a finding, not a finding of absence. Who is represented lists everyone working on this topic, including those not cited above.

Where they disagree

No contradictions recorded on this topic yet.

The issues in full

Each issue carries the organizations that name it, the numbers behind it, and the remedies proposed - with the concrete steps under each. Every citation points at a section of a named document, so any count here can be checked.

Issue 012 organizations name it1 qualifies it2026 evidence

The agent is only as safe as the tools it may call, and those were not reviewed

Attention goes to the model and its prompts. The attack surface is largely the tools it can invoke, which were built as internal services and never assessed as something an autonomous caller would reach.

A misconfigured or vulnerable tool widens both what an attacker can reach and what the consequence is, because the agent will call it faster and more often than a person would. The controls are ordinary application security - sanitise inputs, enforce access control at the tool rather than in the prompt, and test the tools the way any other exposed service is tested - but they are rarely applied here, because the tool predates the agent and was reviewed under the assumption that a human was on the other end of it.

How to fix it — 1 approach, 3 steps

Security-review every tool an agent may call

Treat the tool list as the attack surface. Each tool gets the review an externally exposed service would get, with access control enforced at the tool rather than in the prompt.

Done when A tool register lists every tool each live agent may call with its owner and the date of its last security review, and a call carrying an agent credential that should not have it is refused by the tool itself.

  1. List every tool each live agent may call, and who owns it.0-30 daysHead of architecture
  2. Enforce authorisation at each tool, not in the agent instructions.30-90 daysHead of security engineering
  3. Put the tools into the same security testing cycle as exposed services.90-180 daysHead of security engineering
The evidence — 7 documents
OrganizationDocumentPosition
CISAOther · April 2026Careful adoption of agentic AI servicesOur reading Names third-party components as a distinct route rather than a subset of supply chain risk: integrated without a privilege review, they arrive holding entitlements beyond what the workflow needs, and compromising one low-consequence tool inherits whatever the agent around it can reach. Notes that tool integration commonly runs in both directions, so the tool is not only something the agent calls but something that can return instructions to it.The component nobody reviewed, carrying privilege nobody grantednames it
Palo Alto NetworksVendor · May 2025Agentic AI threatsOur reading Reports that misconfigured or vulnerable tools significantly increase both the attack surface and the impact, and that insufficient access control at the backend is what makes some of these straightforward to exploit.Misconfigured and vulnerable toolsnames it
AnthropicFrontier lab · July 2026Anthropic’s CISO guide to agentic AIOur reading Proposes limiting reachable surface as the primary control, which makes the tool list the thing to review.Constrain what the agent can reachproposes a fix
AWSHyperscaler · April 2025Navigating the security landscape of generative AIOur reading Extends least privilege past the agent to the external integrations it reaches, and asks for those to be audited, reviewed and patched on a continuing basis rather than assessed once at build time.Treat every integration as part of the agentproposes a fix
Cloud Security AllianceInstitutionAgentic AI Identity and Access ManagementOur reading Qualifies where the check has to sit: enforcement at the resource rather than in the instructions, because instructions are advisory to an optimiser.Authorisation belongs at the resourcequalifies it
FS-ISACInstitution · April 2026Preparing the enterprise for AI-enabled vulnerability discoveryOur reading Proposes a control rarely written down: deliberately delay taking on new open-source software or new models, so there is an interval in which a vulnerability can be found and fixed by somebody else before the thing is load-bearing. Pairs it with a freshness floor in the other direction - nothing internal or third-party more than two major versions behind - so the delay is bounded rather than becoming its own exposure.Let a new dependency age before you depend on itproposes a fix
Palo Alto NetworksVendor · May 2025Agentic AI threatsOur reading Proposes input sanitisation, strict access control and routine static and dynamic security testing of the tools themselves rather than of the model alone.Sanitise inputs and test the toolsproposes a fix

Issue 022 organizations name it1 qualifies it2026 evidence

The control is understood, documented, and switched off where the work happens

Guardrails are specified centrally and disabled in the environments that matter - research, evaluation, staging, the fast-moving team - because they cost latency and get in the way.

This is not ignorance of the control; it is a local trade made without anyone holding the aggregate. The published account of an evaluation run with production classifiers deliberately removed is the clearest available illustration, and it was a deliberate, disclosed research decision - which is more than most organizations can say about their own disabled controls. The question to ask is not whether guardrails exist but where they are currently not running, who decided that, and whether anybody outside that team knows.

How to fix it — 1 approach, 3 steps

Inventory where each control is not running

Produce, per environment, the list of controls that are specified but not currently enforced, and who decided that.

Done when A per-environment list of controls that are specified but not enforced exists, and every entry on it carries a named approver and an expiry date that has not passed.

  1. List every environment where models run, including research and evaluation.0-30 daysCISO
  2. For each, record which specified controls are not enforced and on whose authority.30-90 daysHead of security engineering
  3. Require a named approver and an expiry date for any control left off.30-90 daysCISO
The evidence — 4 documents
OrganizationDocumentPosition
AnthropicFrontier lab · July 2026Anthropic’s CISO guide to agentic AIOur reading Names the condition a control has to meet to still be there at the moment of work: it must live somewhere the agent's own environment cannot reconfigure or route around - the egress path, the tool list, an organization-wide off switch - because anything placed in the prompt or the scaffold gets engineered out as the systems change.Where a control has to sit to survivenames it
OpenAIFrontier lab · July 2026Security incident during model evaluation, with Hugging FaceOur reading States that the evaluation deliberately ran without the classifiers used in production to prevent high-risk cyber activity, in order to estimate maximal capability - a disclosed research choice that also describes the common enterprise pattern exactly.Evaluation run without production classifiersnames it
AWSHyperscaler · April 2025Navigating the security landscape of generative AIOur reading Proposes classifying each use case by how much of the system the organization actually controls - from a consumer application it merely buys through to a model it trains itself - and setting the control, governance and resilience expectation from that position, instead of holding every use case to one standard.Set the control bar from how much of the stack you ownproposes a fix
AWSHyperscaler · April 2025Navigating the security landscape of generative AIOur reading Qualifies the problem past switches: the perimeter and data-access controls an organization already runs are treated as necessary but not sufficient here, because the vectors this technology adds sit outside what they were designed to see. A control inventory can therefore read as complete while the AI path is uncovered.The controls left switched on were built for something elsequalifies it

Issue 03Our analysisnewest evidence Jul 2024

Guardrails have a per-call cost that no business case carries

Filtering, validation and classification add latency and inference spend to every request. The business case counted the model, not the controls around it.

This matters because it decides whether the control survives contact with a latency target. A guardrail that doubles response time is not removed by a policy decision; it is removed by an engineer under pressure to hit a number, and the removal is rational within the frame they were given. Costing the control alongside the model, in the same case, is what makes the trade visible to the person who is accountable for both.

How to fix it — 1 approach, 2 steps

Put the control cost in the same case as the model cost

Any approved deployment carries the measured latency and spend of its controls in its own business case, not in a separate security budget.

Done when At least one deployment business case states the measured latency and per-call cost of its own controls, and carries an approval dated after those figures were added to it.

  1. Measure added latency and cost per call for the controls on one live system.0-30 daysHead of security engineering
  2. Add that figure to the deployment business case and re-approve against it.30-90 daysCFO
The evidence — 1 document
OrganizationDocumentPosition
NISTInstitution · July 2024Generative AI Profile (NIST AI 600-1)Our reading Sets out the ongoing actions a deployment carries rather than one-off gates, which is where the recurring cost sits.Actions across the lifecycleproposes a fix

Who is represented

This dossier is drawn from 30 organizations working on the subject, 8 of which are cited directly in the issues above.

Consultancy — 11

McKinsey & Company 4 Capgemini 3 Accenture 2 Boston Consulting Group 2 Deloitte 2 KPMG 2 Booz Allen Hamilton 1 Cognizant 1 EY 1 Infosys 1 UST 1

Institution — 4

Cloud Security Alliance 2 FS-ISAC 1 NIST 1 World Economic Forum 1

Academic — 1

arXiv (research) 1

Hyperscaler — 5

AWS 4 IBM 4 Microsoft 2 Google Cloud 1 ServiceNow 1

Frontier lab — 2

OpenAI 3 Anthropic 2

Enterprise — 2

Airbnb 1 Palantir 1

Vendor — 3

Palo Alto Networks 1 Eightfold AI 1 Menlo Ventures 1

Other — 2

CISA 1 Dario Amodei (Anthropic) 1