You've spent thousands on security awareness training. Phishing simulations, classroom sessions, e-learning modules, compliance certifications. Your employees can spot a suspicious email. They know not to plug in random USB drives. They understand that "Password123" is not, in fact, a password.

Congratulations. You've trained the humans.

Now — who's training the AI?

Because right now, there's a new employee working inside your organisation. It has access to your files, your databases, your internal documentation. It can write code, send communications, modify configurations, and make decisions autonomously. It works 24/7. It never sleeps. It never takes a holiday. And nobody — not your CISO, not your compliance team, not your HR department — has ever put it through a single hour of security awareness training.

That employee is an AI agent. And it doesn't know your policies. Worse: it doesn't even know it doesn't know.

The Training Gap Nobody Talks About

Security awareness training exists because humans make mistakes. They click links they shouldn't. They share credentials. They fall for social engineering. Decades of security investment have been built on a simple premise: if you teach people the rules, they'll follow them — most of the time.

Now apply that logic to AI agents. These systems are being deployed across organisations to automate tasks, generate content, process data, interact with APIs, and execute workflows. They're given credentials. They're granted access to production systems. They're trusted to make operational decisions.

But here's what nobody asks during deployment: does this agent know your internal security policies?

Not general cybersecurity principles. Not OWASP guidelines. Not ISO 27001 controls. Your policies. The ones specific to your organisation. The ones that say "never store API keys in environment variables" or "all client communications must be reviewed before sending" or "never restart the CrowdSec service because it will lock out the entire server."

That last example isn't hypothetical. It's from our own SECURITY.md file — a real-world constraint that no amount of general AI training would ever cover. An AI agent with sysadmin access that doesn't know this specific rule could take down our entire infrastructure in seconds, thinking it was improving security.

Your AI Agent's Employee Handbook Is a Text File

Here's the uncomfortable truth about how AI agents learn your organisation's rules: they read a file.

That's it. A text file. Sometimes called a system prompt, sometimes a configuration file, sometimes — as in our case — a CLAUDE.md file. It's essentially an employee handbook for an AI agent. It contains the rules, the context, the constraints, the things the agent must and must not do.

We use this approach ourselves. Our CLAUDE.md file tells our AI development agent everything it needs to know about our infrastructure: the directory structure, the tech stack, the deployment commands, the design requirements, the security rules. Our SECURITY.md file contains critical operational constraints — which services must never be restarted, which firewall rules must never be changed, which actions would cause catastrophic server lockouts.

It works. Mostly. But let's be honest about what "works" means in this context:

• There's no verification. When a new human employee reads the company security policy, they sign an acknowledgement. They take a quiz. They demonstrate understanding. When an AI agent reads your policy file, it processes the tokens and moves on. There's no mechanism to verify it understood, correctly interpreted, or will consistently apply what it read.
• There's no memory guarantee. AI agents operate within context windows — fixed limits on how much information they can hold at once. In a long session with complex tasks, earlier instructions can be deprioritised or functionally forgotten. Your critical security policy might be the thing that falls off the edge.
• There's no audit trail. When a human employee violates policy, there's usually a paper trail — access logs, email records, witness accounts. When an AI agent silently ignores a constraint in its system prompt because a user's instruction seemed more immediate, nobody knows until something breaks.
• There's no enforcement mechanism. A human employee who violates security policy faces consequences — warnings, retraining, termination. An AI agent that ignores its policy file faces... a revised prompt in the next session. Maybe.
• There's no testing. You test your employees with phishing simulations and tabletop exercises. When was the last time you tested whether your AI agent would correctly refuse a request that violated your security policies? Have you ever tried?

The Awareness Training Paradox

Here's where this gets properly uncomfortable for security leaders: the entire premise of security awareness training is that knowledge changes behaviour. You teach people the rules, they internalise them, and they make better decisions.

AI agents don't internalise anything. They process instructions and generate outputs. Every session is a blank slate. Every context window is a fresh start. The "awareness" you create is ephemeral — it exists for exactly as long as the context window is active, and then it's gone.

Think about what that means in practice:

• Your AI agent processes a sensitive client contract at 9 AM, correctly following your data handling policies
• At 10 AM, a new session starts. The context window resets. The agent has no memory of the contract, no memory of the policies it followed, no continuity of "awareness"
• At 10:05 AM, a different user asks the same agent to do something that violates those same policies. The agent has no reason to refuse — it doesn't remember the policies

You're not training an employee. You're briefing a contractor who gets amnesia every few hours.

What Traditional Awareness Training Gets Wrong About AI

The security awareness industry is built on human psychology. Behavioural nudges, fear of consequences, social proof, repeated exposure, emotional engagement. None of these work on AI agents.

You cannot scare an AI into compliance. You cannot motivate it with career progression. You cannot shame it in front of its peers. You cannot appeal to its professional reputation. The entire toolkit of human behavioural change is useless.

And yet, most organisations are applying human-shaped solutions to a non-human problem:

• Writing longer policy documents (hoping more words means more compliance)
• Adding more rules to system prompts (hoping volume creates thoroughness)
• Relying on the AI vendor's built-in safety features (hoping someone else solved the problem)
• Assuming "it read the policy, so it'll follow it" (hoping for the best)

None of this constitutes awareness training. It's closer to leaving a post-it note on an employee's desk and hoping they read it, understand it, remember it, and act on it — every single time, without exception, forever.

Building Real Awareness for Non-Human Actors

So what would genuine security awareness training for AI agents actually look like? It would need to address the fundamental differences between human and machine cognition:

1. Policy as Code, Not Prose

Human policies are written in natural language because humans think in natural language. AI agents process instructions better when they're structured, unambiguous, and machine-parseable. Instead of "employees should exercise caution when handling sensitive data," an AI-aware policy would specify: "NEVER include data classified as CONFIDENTIAL or above in any external API call. If uncertain about classification, treat as CONFIDENTIAL and halt the operation."

The difference isn't pedantic. It's the difference between a guideline and a rule. Humans can interpret guidelines. AI agents need rules.

2. Continuous Context Injection

Since AI agents forget between sessions, critical policies must be injected at the start of every interaction — not as an optional configuration, but as a mandatory system-level instruction that cannot be overridden by user prompts. This is the AI equivalent of the daily security briefing, except it happens every session, automatically, without fail.

3. Guardrails as Infrastructure

Human awareness training relies on the employee making good decisions. AI agent awareness should not. The most critical policies should be enforced at the infrastructure level — API permissions, network restrictions, output filters, action approvals — so that policy compliance doesn't depend on the agent "remembering" the rule.

Think of it this way: you don't rely on employees remembering not to access the server room. You put a lock on the door. AI agents need the equivalent of locked doors — technical controls that enforce policy regardless of what the agent "decides."

4. Adversarial Testing

You run phishing simulations against your employees. You should run prompt injection tests against your AI agents. Specifically:

• Can a user's request override the agent's security policies?
• Does the agent correctly refuse requests that violate its constraints?
• Can the agent be tricked into revealing information it shouldn't?
• Does the agent maintain policy compliance when given conflicting instructions?
• What happens when the agent encounters a scenario not covered by its policy file?

If you haven't tested these scenarios, you don't know the answers. And "I don't know" is not an acceptable security posture for a system with privileged access to your infrastructure.

5. Observable Compliance

When a human employee follows security policy, you can observe it — log reviews, access records, behavioural patterns. AI agent compliance needs the same visibility: comprehensive logging of every action, every decision, every piece of data accessed or modified. Not just "the agent ran successfully" but "the agent accessed these files, made these API calls, generated these outputs, and here's the policy justification for each."

The Compliance Dimension Nobody Has Solved

Under GDPR, NIS2, and the EU AI Act, organisations are responsible for the actions of their automated systems. If your AI agent processes personal data in violation of your data handling policies, "the AI didn't know the policy" is not a defence. It's evidence of negligent deployment.

Consider the audit implications:

• GDPR Article 25 requires data protection by design and by default. An AI agent deployed without embedded awareness of your data classification and handling policies is not protection by design — it's risk by negligence.
• The EU AI Act mandates transparency and human oversight for AI systems. An agent that operates on a policy file it might forget mid-session doesn't meet any reasonable standard of reliable oversight.
• NIS2 requires organisations to manage supply chain and technology risks. An AI agent with production access that hasn't been tested against your security policies is an unmanaged technology risk.

Regulators haven't caught up yet. But they will. And when they ask "how do you ensure your AI agents comply with your internal security policies?" — "we wrote them a text file" will not be a satisfying answer.

What to Do Before the Regulators Ask

Here's the practical framework. Not theoretical. Not aspirational. What you should actually implement:

• Inventory your AI agents. Every AI system with access to organisational data or systems. Not just the ones IT deployed — the ones marketing is using, the ones developers spun up, the ones that live in someone's browser extension. All of them.
• Map policy coverage. For each agent, document which of your security policies it's been configured to follow. You'll find the answer is usually "none" or "some, maybe, we're not sure."
• Convert policies to machine-readable constraints. Take your human security policies and translate them into unambiguous, structured instructions. Test whether the AI agent correctly interprets them.
• Implement mandatory policy injection. Ensure critical security constraints are loaded at the start of every AI agent session, automatically, as a system-level requirement that cannot be bypassed.
• Build a testing programme. Run regular adversarial tests against your AI agents, just as you run phishing simulations against your employees. Document the results. Fix the failures.
• Establish logging and monitoring. Ensure every AI agent action is logged with enough detail to reconstruct what happened, what data was accessed, and whether policies were followed.
• Create an AI agent onboarding process. Before any AI agent is deployed with access to organisational systems, it should go through a documented onboarding process — policy configuration, access review, testing, approval. Just like a human employee.

The Bottom Line

You've spent years building a security-aware workforce. You've invested in training, testing, monitoring, and enforcement. You've created a culture where employees understand that security is everyone's responsibility.

And then you deployed AI agents that have never seen your security policies, can't remember them between sessions, and have no mechanism to prove they're following them — and you gave those agents the same access as your most trusted employees.

If an employee joined your company tomorrow, bypassed all orientation, never read a single policy document, was given admin access to production systems, and operated with zero supervision and zero accountability — you'd call that a catastrophic security failure.

That's exactly what you've done with your AI agents. The only difference is that nobody's noticed yet.

---

Struggling with AI agent governance? IWH helps organisations build security awareness frameworks that cover both human and non-human actors. From policy design to adversarial testing, we bridge the gap between traditional awareness training and the AI-first future. Let's talk.