Security as Enablement, Not Commentary¶
If your security function's primary output is a narrative about another team, you are not reducing risk. You are generating a backlog item competing for priority against revenue, customer experience, and regulatory change.
The Heckling Problem¶
There is a pattern that every delivery team recognises: corporate functions that drift from enablement into commentary. They attend steering forums, publish decks, rate maturity, explain what good looks like, and diagnose other teams from a safe distance — without ever carrying the burden of delivering anything meaningful themselves.
The description of what this looks like in cyber security is uncomfortably precise:
"A penetration test report is not value. A spreadsheet of findings is not protection. A quarterly email with severity ratings is not security. If the same issues reappear release after release, the problem is not developer immaturity. It is systemic enablement."
And then the line that should be printed on the wall of every security operations centre:
"Give teams tools that solve real problems and they will use them. Give them a list of issues and you will be negotiated."
This framework exists because we believe that AI systems need runtime behavioural security. But if the framework is consumed as narrative — as a maturity model to diagnose teams with, as a checklist for a governance function to enforce from the sidelines, as a deck explaining why delivery teams are not good enough — then it has become exactly the heckling tool it was supposed to prevent.
The framework must be delivered as infrastructure, not as commentary. This article maps the specific design decisions that prevent the framework from becoming the problem it was built to solve.
How Security Frameworks Become Heckling Tools¶
A security framework drifts into heckling through a predictable sequence:
1. The framework is published. A central function produces a comprehensive document describing what good looks like. It contains risk tiers, control matrices, checklists, maturity models, and reference architectures. It is thorough. It is coherent. It has diagrams.
2. The framework is distributed. Delivery teams are told to "align" to the framework. They receive a document. They do not receive a platform, a library, a pipeline component, or any artefact that reduces friction. They receive narrative.
3. Delivery teams are assessed against the framework. A governance function reviews delivery teams and identifies gaps. These gaps are documented. The delivery teams are rated. Their maturity is scored. The assessment is shared with leadership.
4. The delivery teams push back. They explain that the gaps exist because of constraints the governance function never absorbed — regulatory pressure, technical debt, integration complexity, competing priorities, incomplete information, and immovable deadlines. The governance function has all the answers because it has none of the constraints.
5. Alignment sessions are convened. Both sides present. Both sides moderate. Both sides leave with a shared document that looks like consensus but mostly reflects exhaustion. Nothing changes. The delivery team continues largely as it was. The governance function moves to the next assessment.
The framework produced no code, no platform capability, no reusable component, no reduction in friction. It produced narrative. And narrative, no matter how correct, is not security.
The Anti-Patterns This Framework Must Avoid¶
1. Risk Tiers as Team Ratings¶
The framework classifies systems, not teams. The moment someone uses a risk tier to say "this team is at Tier 1 maturity," the framework has been weaponised as a heckling tool.
A team deploying a low-risk internal chatbot at Fast Lane is not "less mature" than a team deploying an autonomous credit decision system at Tier 3. They are deploying different systems with different risk profiles. The controls are proportionate to the risk, not to anyone's assessment of the team's capability.
If risk tiers appear on a slide next to team names in a governance forum, something has gone wrong.
2. Checklists as Gates¶
The framework contains checklists. Pre-deployment verification, ongoing governance, PACE resilience validation. These exist to help delivery teams confirm readiness. They do not exist so that a governance function can score compliance from outside.
If a checklist requires sign-off from a function that did not participate in the build, it is a gate. If it is automated validation in the deployment pipeline, it is a guardrail. The same checklist becomes either enablement or heckling depending on where it lives and who operates it.
3. Judge Findings as a Spreadsheet of Issues¶
The LLM-as-Judge evaluates AI outputs and surfaces findings: PASS, REVIEW, ESCALATE. If those findings go to a security team's dashboard where they are compiled into a quarterly report and presented to the delivery team as evidence of deficiency, the Judge has become a backlog generator.
Judge findings must go to the owning team, in their existing workflow tools, with actionable context. A finding without context is not a finding — it is an interruption. A finding that arrives in Jira with reproduction steps, severity, and a suggested remediation is a tool. A finding that arrives in a governance deck as "42 ESCALATE findings in Q3" is heckling.
4. PACE Plans as Governance Documents¶
PACE resilience defines what happens when controls degrade: Primary, Alternate, Contingency, Emergency. If the PACE plan is a document that a delivery team writes to satisfy a governance requirement, it will be accurate on the day it was written and fictional within six months.
If the PACE plan is implemented as platform infrastructure — circuit breakers that activate automatically, fallback routes that are pre-configured, kill switches that are tested monthly — then it is a resilience system. Documents describe intent. Infrastructure enforces it.
5. The Framework Itself as a Counter-Narrative¶
The most insidious form of heckling is the seductive counter-narrative. Because the heckler carries no production responsibility, they have spare capacity to construct compelling alternatives. Cleaner models. Simpler approaches. Visions unburdened by delivery.
A security framework is, inherently, a counter-narrative. It describes a world in which every deployment is classified, every control is implemented, every resilience plan is tested, and every human reviewer meets their SLA. Delivery teams have already considered most of these concerns. They have already debated alternatives. They have made deliberate choices under constraints the framework's authors never encountered.
If the framework is used to argue "your architecture is wrong because it doesn't match our reference pattern," the person making that argument must also be accountable for helping fix it. Counter-narratives produced without delivery accountability are not strategy. They are expensive theatre dressed as governance.
How the Framework Should Function¶
The framework already contains the right principles. The challenge is ensuring those principles survive contact with organisational reality.
Principle 1: The Secure Path Must Be the Easiest Path¶
The formulation is simple: a cyber team that works with platform teams to harden pipelines, embeds guardrails into CI/CD, provides reusable components to prevent entire classes of vulnerability, and supplies consumable building blocks which make the secure path the easiest path — is a team creating value.
For this framework, that means:
| Framework Component | Heckling Version | Enablement Version |
|---|---|---|
| Guardrails | A document describing what guardrails a team should implement | A platform service that applies guardrails automatically when a team deploys on approved infrastructure |
| LLM-as-Judge | A requirement that teams build and operate their own evaluation pipeline | A shared service that evaluates transactions and routes findings to the owning team's workflow |
| Risk classification | A questionnaire that requires a meeting with the security team to complete | A self-service form that returns a tier and auto-applies the corresponding controls |
| Logging | A policy requiring teams to implement comprehensive logging | A platform that captures all AI interactions by default because teams deploy on infrastructure that logs |
| PACE resilience | A template that teams must fill in and submit for approval | A platform capability where circuit breakers, fallback routes, and kill switches are pre-configured per tier |
| Kill switch | A documented process for disabling an AI feature | A feature flag that exists from day one because the platform provisions it automatically |
The pattern is consistent: the framework's value is realised when its controls are platform primitives that teams inherit by deploying, not documents that teams must implement independently.
Principle 2: Fast Lane Must Be the Default Experience¶
The Fast Lane is the framework's most important feature. It defines criteria under which AI can be deployed without security review. Internal, read-only, no regulated data, human-reviewed. Self-certification. No waiting.
Most AI deployments in most organisations will qualify for the Fast Lane. If the majority of teams experience the framework as a heavyweight process, the framework has failed — not because the controls are wrong, but because the entry point is wrong.
The Fast Lane is not a concession. It is the design. The framework is designed so that low-risk deployments are frictionless, and security teams spend their time on the deployments that actually need them.
If the Fast Lane feels like an exception rather than the norm, the organisation has inverted the framework's intent.
Principle 3: Embed, Don't Narrate¶
The solution to corporate heckling is reintegration. Move architects into delivery teams. Embed risk practitioners into sprint ceremonies. Put UX designers in the room when engineering trade-offs are being made. Give cyber teams ownership of platform controls rather than audit findings.
For this framework:
Security engineers should own the platform controls, not the assessment process. A security team that builds and operates the guardrail service, the Judge pipeline, the logging infrastructure, and the kill switch mechanism is delivering value. A security team that reviews delivery teams against the framework and produces a maturity score is heckling.
Risk practitioners should be present when classification decisions are made. If a team classifies a system at Tier 1 and a risk function later disagrees, the failure is not the team's classification — it is the risk function's absence from the conversation that mattered.
The framework should be operated by people who carry outcomes. If the person enforcing the framework is not accountable for the system's success — not just its compliance, but its actual production performance — they will optimise for the framework's narrative rather than the system's reality.
Principle 4: Produce Tools, Not Findings¶
The strategy section describes the framework's philosophy as "guardrails, not gates." This must extend to implementation.
Every control in the framework should be evaluated against a simple test: does it produce a tool, or does it produce a finding?
| Output | Example | Assessment |
|---|---|---|
| Tool | A PII detection library that redacts sensitive data before it reaches the model | Enablement — reduces a class of vulnerability |
| Finding | "PII was detected in 12 outputs last quarter" | Heckling — generates a backlog item |
| Tool | A prompt injection classifier integrated into the API gateway | Enablement — blocks attacks without team action |
| Finding | "Your guardrails do not cover Base64-encoded injection patterns" | Heckling — describes the problem without solving it |
| Tool | A Judge service with pre-built evaluation criteria for common use cases | Enablement — teams deploy with assurance built in |
| Finding | "Your system lacks independent output evaluation" | Heckling — correct observation, zero friction reduction |
This is the framework's existing principle of infrastructure beats instructions applied to the security function itself. Don't instruct delivery teams to implement controls. Build the controls into the platform. Make the secure path the path of least resistance. Make insecurity harder than security.
Principle 5: Never Rate Maturity¶
Maturity is not declared in a deck. It is built in code, in platforms, in patterns that actually make delivery easier, and it is built by people who carry outcomes rather than narratives.
The framework contains a Maturity & Validation document. It is honest about what is validated, what is emerging, and what remains unproven. This is the right kind of maturity assessment — it evaluates the framework's own evidence base.
What the framework must never become is a tool for assessing delivery team maturity. "Team X is at Level 2 maturity against the AI security framework" is a statement that carries no delivery accountability. It describes another team's position from a safe distance. It is the definition of heckling.
If you want to know whether a team's AI system is secure, look at the controls running in production. Are guardrails deployed? Is the Judge evaluating outputs? Are findings being triaged? Is the kill switch tested? These are observable facts, not maturity scores. They are built in infrastructure, not declared in decks.
The Bar Raiser Distinction¶
There is a distinction between the heckler and the bar raiser. The heckler arrives with a pre-formed narrative. The bar raiser arrives with pattern recognition earned from having delivered.
A security function operating this framework as a bar raiser looks like this:
- They sit in discovery sessions and help classify risk before teams commit to an architecture
- They build platform capabilities that make controls automatic
- They debug Judge false positives alongside the delivery team
- They participate in PACE failover exercises and carry accountability for whether the failover works
- They help teams navigate the framework's own tensions — where controls conflict with delivery speed, where risk tiers don't cleanly map, where the framework is silent on a novel use case
- They celebrate when a Fast Lane deployment ships in a week with minimal friction
A security function operating this framework as a heckler looks like this:
- They assess teams against risk tiers after the architecture is already built
- They publish findings from Judge output without investigating context
- They enforce checklists without having participated in the work the checklist covers
- They demand PACE documentation without building PACE infrastructure
- They rate team maturity using the framework's categories
- They appear only to say no, redraw diagrams, and demand alignment to abstract models
The difference is not the framework. It is whether the people operating it carry outcomes or carry narratives.
Implementation Guidance¶
For organisations adopting this framework, the following operating principles prevent it from becoming a heckling tool:
1. Security teams build the platform, not the assessments. The primary output of the security function should be running infrastructure: guardrail services, Judge pipelines, logging systems, kill switches. If the security team's primary output is documents about other teams, restructure.
2. Classification is self-service. The five impact questions that determine risk tier should be a form that any team can complete, producing an immediate result. If classification requires scheduling time with a governance function, it is a gate.
3. Controls auto-apply by tier. When a team deploys on the AI platform at a given risk tier, the corresponding controls activate automatically. Teams should not implement controls manually unless they are building something genuinely novel.
4. Findings go to teams, not to governance decks. Judge findings, guardrail blocks, anomaly alerts — all of these route to the owning team's existing workflow. If a governance function compiles these into a cross-team dashboard, that dashboard must be visible to the teams as well, and its purpose must be resource allocation, not blame.
5. Every assessment carries accountability. If a security function identifies a gap, it must also propose a practical remediation that accounts for the team's constraints. "Your system needs enhanced guardrails" without "and here is the library that implements them" is not a gap analysis. It is commentary.
6. The framework evolves through delivery, not through governance. When the framework's controls conflict with delivery reality, the framework changes. The Framework Tensions section explicitly invites this. Strategy that tests the framework's limits is feedback, not non-compliance.
7. Removing controls is a product decision, not a security decision. Controls exist by default. They are platform infrastructure. They are not optional because a delivery team finds them inconvenient — they are the baseline. If a product owner wants a control removed, weakened, or scoped differently, that is their prerogative. But it is their decision, made explicitly, with full understanding of what the control was preventing.
This means the product owner must:
- Decide. The request to remove or reduce a control must come from the person accountable for the product's outcomes. Not from a developer who finds the guardrail annoying. Not from a programme manager trying to hit a date. From the person who owns the product and will answer for its behaviour in production.
- Accept the risk. Removing a control transfers residual risk from the platform to the product. The product owner must understand what that risk is — not in abstract terms, but in concrete terms: what class of failure does this control prevent, and what happens when that failure occurs without it?
- Accept the consequences. If a product owner removes a PII detection guardrail and the system subsequently leaks customer data, that is the product owner's accountability. The security function built the control. The platform provided it by default. The product owner chose to remove it. Accountability follows the decision, not the infrastructure.
This is not a punitive model. It is a clarity model. Security teams should never be in the position of arguing for controls against a product owner who wants them gone. The security team's job is to build the controls and make them available. The product owner's job is to decide which ones apply to their product. If they choose to operate with fewer controls than the framework recommends for their risk tier, that choice is documented, the residual risk is quantified, and the accountability is unambiguous.
The alternative — where security teams own the decision about which controls are required — creates exactly this heckling dynamic. Security becomes the function that says no from the sidelines. Product owners become the teams that negotiate around controls they had no part in selecting. Neither side carries the other's constraints. Both sides produce narratives. Nothing ships.
Make the controls default. Make removal a product decision. Make the consequences visible. Then get out of the way.
The Bottom Line¶
This framework describes what must be true about AI systems in production. How those truths are delivered determines whether the framework creates value or creates noise.
Delivered as platform infrastructure — as shared services, automated pipelines, self-service classification, and pre-configured resilience — the framework reduces friction for delivery teams while maintaining security outcomes. The secure path is the easiest path. Teams adopt it because it makes their work faster, not because a governance function told them to.
Delivered as narrative — as maturity models, assessment frameworks, compliance checklists, and quarterly reports — the framework becomes exactly the corporate heckling it was designed to eliminate. Confident, loud, and useless.
The framework's value is not in the document. It is in the infrastructure that implements it.
Build the controls. Ship them as platforms. Embed your people in delivery teams. Carry outcomes, not narratives.
Everything else is heckling.
AI Runtime Behaviour Security, 2026 (Jonathan Gill).
This article represents the personal views and opinions of the author alone. It is not affiliated with, endorsed by, or representative of any employer, organisation, or other entity. Nothing in this article should be construed as reflecting the position or policy of any company or institution with which the author is or has been associated.