Natural Language Security Policy: What It Gets Right

Every security policy starts as a sentence. "Don't let anyone merge a critical vulnerability." "Tell the platform team on Slack when a secret shows up in a tier 1 repo." "No log4j in our Java services." The sentence is clear to the person who wrote it. The work is turning it into rules a system can evaluate on every pull request, with the right scope, the right action and no surprises.

For years that translation was manual, and natural language security policy is the attempt to automate it. Someone opened a policy builder, picked a rule type, set parameters, chose a scope, and hoped they had captured what the sentence meant. Now a language model can do the translation: you type the sentence, and the policy appears.

Natural language security policy is useful. It is also easy to trust too much. This post covers what plain-English policy authoring is good at, where it breaks, and how to review what a model generates before it starts blocking pull requests.

What natural language security policy means

Natural language security policy is a way of authoring security controls by describing them in plain English and letting a model generate the structured policy behind them. The output is not the sentence. It is the same structured object a person would have built by hand: rules, parameters, an action, a scope and a name.

That distinction matters. The sentence is an interface. The structured policy is what actually runs. A good system shows you the structured policy, lets you edit it, and treats the generation step as a first draft rather than a decision.

Two kinds of policy lend themselves to this well:

• Guardrails: checks that run on a pull request and observe, warn or block.
• Workflows: automations that run when a finding appears or changes, such as filing a ticket, posting a message or starting a fix.

Why plain-English policy helps

It lowers the cost of a first policy

The blank policy builder is a real barrier. Someone new to the tool has to learn the rule catalog before writing anything, which means most organizations run the handful of policies the vendor shipped and nothing else. A sentence box gets a first custom policy written in minutes.

It keeps intent next to implementation

A policy called "Block PRs that introduce critical vulnerabilities" says what it is for. A policy called "Guardrail 14" with three nested rules does not. When the description is the starting point, the name and intent tend to survive.

It moves policy authoring closer to the people who own the risk

An AppSec lead who knows exactly what the rule should be, but has never used the builder, can write it without waiting for the one person who knows the tool.

Where natural language security policy breaks

The failure modes are predictable, because they are the failure modes of language itself.

Ambiguous action words

"Flag critical vulnerabilities." Does flag mean record silently, warn the developer or block the merge? A human would ask. A model has to guess, and a good system guesses conservatively. If the wording does not make the action clear, the safe default is warn, not block.

Implied scope

"Block log4j in production." Production according to what? Branch names, deployment environments, a service tier? Scope is the part of a policy people leave implicit most often, and the part that matters most for blast radius. Generated policies should default to a broad but non-blocking scope, or ask, rather than invent an environment filter.

Hidden AND versus OR

"Warn on compromised or unmaintained dependencies." In English, that is an OR: warn if either is true. In many policy engines, multiple rules in one policy are combined with AND. If the generator puts both rules in one policy, it may only fire when a dependency is both compromised and unmaintained, which is almost never. Check how rules combine in your engine and whether an OR needs two separate policies.

References to specific things

"Alert the payments team when..." requires resolving "the payments team" to a real team record. A model working from a generic rule catalog cannot know your internal identifiers. Anything that names a specific repository, team or person has to be added or confirmed by hand after generation.

Confident wrongness

The most dangerous output is the one that looks right. A policy with the right name and the wrong threshold, "CVSS high" instead of "CVSS critical", reads correctly in a list and behaves differently in production.

How to review a generated policy

Treat every generated policy like a pull request from a new teammate: probably right, worth checking.

1. Read the rules, not the title. Open the structured view and check every rule and parameter against what you meant.
2. Check the action. Is it observe, warn or block? Does that match the sentence, or was it a default?
3. Check the scope. Global by default is common. Narrow it if the sentence implied a subset.
4. Check how rules combine. If the sentence says "or", confirm the policy fires on either condition.
5. Add specific references by hand. Named teams, repositories and people.
6. Start in observe. Save a new guardrail in observe mode, watch what it matches for a week, then promote it.

Step six is the safety net for everything above it. A policy that matches the wrong things in observe mode costs nothing. The same policy in block mode costs a day of engineering goodwill.

Writing descriptions that generate good policy

The quality of the output tracks the specificity of the input. Descriptions that work well tend to name five things:

• The action: block, warn, notify.
• The severity: critical, high, medium.
• The concern: exploited, compromised, unmaintained, license, secret.
• The target: a package and ecosystem, such as "log4j in Maven projects".
• The destination, for workflows: Slack, Teams, Jira, Linear, email.

Compare:

• "Be careful about bad packages." Too vague to generate anything useful.
• "Block PRs that introduce critical vulnerabilities with a fix available." Specific action, severity and condition.
• "Create a Jira ticket and a Teams message for high-severity SAST findings." Specific trigger, filter and two actions.

What about privacy?

A reasonable first question from any security team: what does the model see? A policy generator does not need your code or your findings to translate a sentence into rules. It needs the catalog of rule types and parameters the policy engine supports. Prefer systems that generate from that catalog alone, and confirm it with the vendor before you type anything sensitive into the box.

Keep the sentence with the policy

One underrated benefit of plain-English authoring is the record it leaves. The sentence someone typed is the clearest statement of what the policy was meant to do. Keep it.

• Put the original description in the policy's name or description field, so anyone reading the list later knows the intent.
• When you edit a generated policy by hand, update the description to match. A description that no longer matches the rules is worse than none.
• Review policies quarterly against their descriptions. If the rules have drifted from the sentence, one of them is wrong.

This is the same discipline as a good commit message: the code says what happens, the message says why. For security policy, the why is what an auditor, a new team member or your future self will ask for first.

Plain English is the interface, not the policy

Natural language makes policy easier to write. It does not make policy easier to get right. The discipline that made hand-built policies safe, review the rules, scope carefully, observe before enforcing, applies just as much when a model wrote the first draft. The difference is that you spend your time reviewing instead of clicking.

How Heeler generates guardrails and workflows from plain English

In Heeler, both PR Guardrails and Autonomous Operations workflows can be created by describing them. Under Describe your own in the create dialog, you type what you want and Heeler generates the structured policy:

• For a guardrail, it generates the rules and parameters (up to five rules), picks an action and defaults to Warn when the wording does not make the action clear, sets a title, and defaults the scope to Global, which you can narrow.
• For a workflow, it assembles the trigger, conditions, actions, name and description, and opens the builder with everything filled in.

Nothing is saved until you review it. You can edit the generated settings, regenerate from a revised description, and step through a review before saving. Conditions that depend on specific records, such as a named repository, team or person, cannot be generated and are added by hand.

The guardrail assistant works only from a generic catalog of rule definitions and does not read your repositories or vulnerability data. Descriptions are limited to 500 characters and generation is rate-limited per user. The AI Guardrail Assistant docs and workflow builder docs list example descriptions and what each generates.

Rules within one Heeler guardrail are combined with AND. To fire on any one of several conditions, create one guardrail per rule.

FAQ

What is natural language security policy?

It is authoring security controls by describing them in plain English and letting a model generate the structured rules, action and scope that actually run.

Can a generated guardrail block pull requests immediately?

It can if you save it in block mode, which is why a generated guardrail should start in observe mode and be reviewed before it enforces anything.

What should I check in a generated policy?

Check each rule and parameter, the action, the scope, how multiple rules combine, and any named team, repository or person, which usually has to be added by hand.

Does the model need access to my code?

It should not. Translating a sentence into policy only requires the catalog of available rules, so prefer generators that work from that catalog alone.

If you have a list of security policies that live only as sentences in a wiki, it is worth seeing how quickly they turn into reviewed, scoped guardrails. Get a demo