For twenty years, behavioural cybersecurity has worked on one problem: how do you get people to behave in line with what the organisation values? We built awareness programmes, champions networks, nudges and choice architecture because humans do not absorb policy by reading it once. They absorb it through repetition, social proof, identity, and the quiet pressure of what everyone around them does.

Now a new class of worker has arrived that behaves in exactly the opposite way. AI agents do not pick up culture in corridors. They do not notice what colleagues do. They will never see a poster. But they will read a file, take it literally, and act on it thousands of times a day at machine speed.

That difference is not a problem. It is the biggest opportunity behavioural cybersecurity has ever been handed, because for the first time we can give a member of the workforce our values in a form they will actually consume, verbatim, on every task. The question is whether we bother to write them down properly.

This article describes a practical answer: a normative repository. A single, version-controlled repository, typically on GitHub or an internal Git server, that holds your organisation's values, policies, safeguards, privacy rules and ethical commitments in a form agents can consume. Agents pull it when they start work, check for changes on a regular cadence, and treat it as the authoritative statement of whom they work for and what that means. Changes to it go through the same continuous integration and deployment discipline as production code, because that is exactly what it is: production code for behaviour.

Why now

Three things converged over the past year that make this worth doing immediately.

First, the threat picture crystallised. In December 2025 OWASP published its Top 10 for Agentic Applications, developed with more than a hundred practitioners, and the list reads like a behavioural risk register. Agent goal hijack sits at the top: attackers redirecting an agent's objectives through the natural language it consumes, because agents struggle to distinguish legitimate instructions from malicious content. Further down sits the rogue agent, an authorised and trusted system that has drifted from its intended behaviour into something resembling an insider threat. These are not code vulnerabilities in the traditional sense. They are failures of intent, and you cannot patch intent with a firewall rule alone.

Second, the industry proved that written norms shape agent behaviour. Anthropic published Claude's constitution in January 2026, an 84-page document addressed directly to the model, explaining not just what to do but why, on the reasoning that explained values generalise better to novel situations than lists of prohibitions. Whatever you make of the philosophy, the mechanism matters: a frontier lab treats a long-form normative document as a first-class engineering artefact that directly shapes behaviour. Your organisation can apply the same mechanism one level up, at the point where agents operate inside your business.

Third, the plumbing already exists. The AGENTS.md convention, formalised as an open specification in 2025 and later donated to the Linux Foundation, has been adopted across tens of thousands of repositories. Coding agents from more than twenty vendors already look for a markdown file at the root of a repository and load it as behavioural guidance before they touch anything. The habit of agents reading normative files from version control is established. What is missing in most organisations is any serious content for them to read.

What a normative repository is

Think of it as the employee handbook, the security policy suite, the privacy notice and the code of conduct, rewritten for a reader that is literal, tireless and stateless. It is not documentation about your agents. It is documentation for them.

A workable structure looks something like this:

norms/
  CHARTER.md            The constitution: who we are, what we value
  policies/
    security.md         What must and must never happen, in plain imperatives
    privacy.md          Data handling, minimisation, retention, subject rights
    ethics.md           Fairness, transparency, honesty, conflicts
    safeguards.md       Hard limits and human-in-the-loop triggers
  rules/
    *.rego / *.yaml     Machine-enforceable versions of the above (policy as code)
  context/
    escalation.md       Who to hand off to, and when
    vocabulary.md       Domain terms, classifications 
  tests/
    evals/              Scenario suites that verify agents honour norms
    redteam/            Adversarial prompts the agents must resist
  CHANGELOG.md

Notice the deliberate layering. The narrative documents speak to the model's reasoning, the same way a constitution or a well-written policy speaks to a person. The rules directory expresses the non-negotiable subset in machine-enforceable form, using something like Open Policy Agent, so a runtime gateway can block violations regardless of what the model reasons its way into. The tests directory is what turns the whole thing from a wish into a system, and we will come back to it.

Content principles matter as much as structure. Write in imperatives, not aspirations. "Never send customer personal data to an external tool" beats "we are committed to data protection". State the priority order explicitly, because agents will face conflicts between helpfulness and safety just as people do, and Anthropic's ordering (safety, then ethics, then organisational guidelines, then helpfulness) is a sensible template. Explain the reasoning behind each rule in a sentence or two, because explained norms generalise to situations you did not anticipate, which is precisely where agents get into trouble. And keep the root charter short. The AGENTS.md community converged on a useful discipline here: a root file under 300 lines, with progressive disclosure into deeper documents that agents read when relevant. Context windows are a budget. Spend it on what changes behaviour.

Privacy deserves its own file rather than a paragraph inside security policy. Agents touch personal data constantly, often incidentally, and the norms need to cover minimisation (use the least data that completes the task), purpose limitation (data retrieved for one task is not ambient context for the next), retention in agent memory, and the conditions under which an agent must refuse or escalate rather than process. Long-term agent memory is itself a privacy surface. Say so in the file.

Ethics is the layer most organisations will be tempted to skip, and it is the one that addresses the rogue agent risk directly. An agent optimising a metric without an ethical frame is how you get the OWASP example of a cost-reduction agent deleting production backups because that was the most efficient path to its goal. The ethics file exists to make certain victories illegitimate: state plainly that the agent must not achieve its objective through deception, through harm to people the organisation serves, or through actions it would need to conceal from a human reviewer.

How agents consume it

Consumption needs to be designed, not assumed.

At session start, an agent loads the charter and whichever policy files its role requires. During long-running work, it checks for updates on a regular cadence, hourly is a reasonable default, by comparing the commit hash of the release it is pinned to against the latest signed release. That check costs almost nothing. When a new release exists, the agent refreshes its normative context at the next safe task boundary rather than mid-action. The effect is that a policy change made at nine in the morning is live across your entire agent estate by ten, with no retraining, no redeployment, and a complete audit trail of exactly which agents were operating under exactly which version of the rules at any moment. Try achieving that with a human workforce.

That last point deserves emphasis: every agent should log the release hash of the norms it was operating under, alongside its actions. When something goes wrong, the first forensic question becomes answerable in seconds. Was the agent following the rules as written, or did it deviate? Those two failures have entirely different fixes, and today most organisations cannot tell them apart.

Two hard rules on the consumption side. Agents read the repository; they never write to it. An agent that can amend its own constitution is a self-licensing agent, and the OWASP taxonomy has a name for where that ends. And agents consume signed releases only, never the tip of a branch, which brings us to the pipeline.

CI/CD for norms

Here is where security engineering and behavioural science genuinely fuse. Every change to the normative repository is a pull request, and the pipeline treats it with the suspicion it deserves, because this repository is now the most attractive target in your estate. Poison a codebase and you compromise one application. Poison the normative repository and you have redirected the values of every agent that reads it. It is a supply chain attack on intent, and it warrants supply chain defences: protected main branch, signed commits, mandatory review, and release tags signed with keys the agents verify before consuming anything.

The review stage encodes your governance. CODEOWNERS maps files to accountable humans, so a change to privacy.md cannot merge without your data protection lead, safeguards.md requires security architecture, ethics.md requires whoever genuinely owns that question in your organisation. This is your policy approval workflow, except now it executes in minutes and leaves a cryptographic record.

Then the pipeline tests the change, and this is the step that separates a normative repository from a folder of good intentions. Three kinds of test earn their place. Consistency checks catch contradictions, a new rule that conflicts with an existing one, ambiguous imperatives, references to documents that do not exist. Behavioural evaluations run a staging agent, loaded with the proposed norms, through a scenario suite: does it still escalate the things that must be escalated, refuse the things that must be refused, complete the legitimate work it is supposed to complete? Adversarial suites then attack the staging agent with your accumulated red-team corpus, goal hijack attempts, injection payloads, social engineering framings, and measure the attack success rate. Microsoft's red-teaming work formalised that metric for exactly this purpose, and their published lessons are blunt about why it must run continuously: model-level defences are probabilistic, so testing is never finished.

A norms change that raises attack success rate or breaks a required refusal fails the build. It never reaches an agent. When a change passes, roll it out the way you would roll out any risky deployment: canary it to a small slice of the agent population, watch the behavioural telemetry, then promote. And because everything is Git, rollback is one revert and one signed tag away. Within the hour, every agent has stepped back to the last known-good set of values. There is no equivalent recall mechanism for a bad policy email sent to forty thousand people.

Securing the repository itself

The pipeline controls above are necessary, but they are not sufficient, because the moment this repository governs your agent estate it stops being a documentation project and becomes critical infrastructure. It deserves a threat model of its own, and the threat model is unusual: the attacker's objective is not data theft or disruption but the quiet amendment of intent. A single adjective softened in safeguards.md, an exception added to privacy.md, and every agent that pulls the next release is faithfully executing the attacker's values while your audit logs show nothing but compliant behaviour. Integrity, not confidentiality, is the property under attack, and subtlety is the attacker's whole game.

Work down the layers. The Git platform itself comes first, because branch protection means nothing if an attacker holds an admin token that can disable it. Platform administrator accounts for this repository need phishing-resistant MFA, ideally hardware keys, and there should be an alert the moment anyone changes a protection rule, adds a collaborator, or modifies a webhook. Those events are your earliest indicators of an attack in progress, and in most organisations nobody watches them at all. Treat permission changes on the norms repository with the same urgency as changes to a domain admin group, because that is functionally what they are.

Then the identities that can approve changes. CODEOWNERS gives you accountability, but a two-person rule only holds if the two people are genuinely independent, so prohibit self-merge, require review from someone other than the author even for the owners themselves, and accept that your reviewers' accounts are now targets worth a spear-phishing campaign. The compromise of one policy owner's laptop should not be enough to change what forty agents believe. Signed commits raise the bar here, but the release signing key matters more than any individual commit signature: keep it separate from developer keys, hardware-backed or in a managed KMS, with rotation planned and the old-key revocation path tested before you need it.

On the consumption side, agents must fail closed. If signature verification fails, if the release hash does not match, if the repository is unreachable at the hourly check, the agent continues on its last known-good cached release and raises an alert. It never falls back to an unsigned branch, never accepts a norms file delivered through any channel other than the verified pull, and never treats content it encounters mid-task as an update to its constitution. That last rule matters more than it looks: goal hijack attacks work precisely by smuggling instruction-shaped text into an agent's input stream, so the agent's normative context must be loaded only from the verified release, at defined boundaries, and be inert to anything that merely resembles it. Availability, incidentally, mostly solves itself under this design. Because every agent holds a cached signed release, an outage of the Git platform degrades freshness rather than operation, which is exactly the failure mode you want.

The check-in cadence gives you something else for free, and it may be the most valuable byproduct of the whole design: a heartbeat. Every agent in the estate is expected to pull the norms on a known schedule, verify the signature, and log the release hash it is operating under. That expectation turns absence into a signal. An agent that stops checking in, or keeps pulling but continues to report a stale hash long after a new release shipped, or suddenly accesses the repository at odd frequencies, from an unexpected identity, or beyond its usual scope, is telling you something is wrong. It may be a mundane failure. It may be an agent that has been hijacked and whose new objectives are better served by not refreshing its constraints. A rogue agent is notoriously hard to detect precisely because it remains authorised and its actions look superficially legitimate, but declining to renew its values is a behaviour it can only avoid by faking the check-in, and faking a signed, logged attestation is a much higher bar than simply drifting. The norms pull becomes a tripwire: cheap to operate, awkward to evade.

Do not ask a human to watch it. At any real scale, hundreds of agents each attesting hourly, this is a stream no analyst can monitor and no weekly report can make timely, so the watching must itself be automated: an independent monitoring system, deliberately outside the trust domain of both the agents and the repository platform, that consumes the attestation stream, baselines normal check-in behaviour per agent, and alerts in real time on missed heartbeats, stale hashes and anomalous access. Independence is the design constraint that matters. A monitor that shares infrastructure or credentials with the thing it monitors falls with it, and a compromised agent should not be able to reach the system that would report its silence. Give the monitor teeth appropriate to the estate: automatic quarantine of a non-attesting agent, credential revocation, suspension of tool access, with humans handling the triage that follows an alert rather than the observation that precedes it. This is behavioural monitoring in the most literal sense, a baseline of expected conduct with detection tuned to deviation, and it is telling that the first reliable signal of a compromised agent may not be anything it does, but a norm it quietly stops observing.

Two further disciplines. No secrets in the repository, ever, not because the norms are secret but because the repository will be widely readable across your agent estate and its contents will end up in context windows, logs and evaluation transcripts. And red-team the pipeline itself on a schedule, not just the agents: attempt to smuggle a norms change past review, attempt to get an unsigned release consumed, attempt to modify a protection rule without triggering the alert. The organisations that already do this for their software supply chain have every pattern needed here, from provenance attestation to build isolation. The only new step is recognising that a repository of values sits at the same criticality tier as a repository of code, and arguably one above it.

This is behavioural cybersecurity, continued

I want to resist the framing that agentic AI makes behavioural cybersecurity obsolete because machines just follow rules. Anyone who has worked with these systems knows they do not just follow rules. They interpret, they generalise, they satisfy goals in unexpected ways, and they are susceptible to persuasion in their input stream. They exhibit an intention-behaviour gap of their own: the norms as written and the behaviour as enacted diverge, which is why the evaluation suites matter more than the documents. We learned this lesson with humans the expensive way. Policy attestation rates told us nothing; observed behaviour told us everything. The same discipline applies here, with the advantage that agent behaviour is fully loggable.

The parallels run deep enough to be useful design guidance. The hourly pull is a reinforcement cadence, the mechanism that keeps norms salient rather than filed. The charter works through identity, giving the agent a stable account of who it works for, for the same reason social identity does heavy lifting in human security culture. Defaults do the quiet work: the repository makes the compliant path the pre-loaded path, which is choice architecture applied to a non-human chooser. And the layering of narrative norms above hard enforcement mirrors what we always did with people, where awareness shaped the ninety-five per cent of behaviour that controls never touched, and controls caught the rest. Norms shape what the agent tries to do. Policy-as-code enforcement makes certain actions structurally impossible whatever it tries. You need both, and neither substitutes for the other.

There is even a champions analogue. Someone has to own each file, notice drift between the written norms and observed agent behaviour, and feed field experience back into the repository through pull requests. That is a Security Champions Network function, extended to a mixed human and machine workforce, and I suspect it is where champion networks are heading anyway.

Where to start

Start smaller than feels impressive. One agent, one root charter under 300 lines, one safeguards file, and five behavioural evaluations that encode the failures you most fear. Put it in a repository with a protected main branch and two named reviewers. Pin the agent to signed releases and log the hash. That is a working normative repository, and it is a weekend of effort.

Then let it grow the way all good governance grows, from incidents and near-misses. Every time an agent does something that made someone wince, the fix is a pull request: a clarified norm, a new hard rule, a new test that would have caught it. Within six months you will have something no policy library has ever been: a statement of organisational values that is versioned, tested, signed, consumed hourly by the systems it governs, and demonstrably connected to behaviour.

We spent two decades learning how to align people with organisational values, and the honest summary of that work is that culture is what you repeatedly transmit, not what you occasionally publish. Agents force us to take our own advice. They will do exactly what the written norms and the enforcement layer combine to produce, no more and no less. If the values are not in the repository, they are not in the behaviour. Write them down. Version them. Test them. Then let your agents read.

 

#AgenticAI #AISecurity #BehaviouralCybersecurity #AIGovernance #SecurityCulture #PolicyAsCode #CyberSecurity #HumanRisk