# AI Security in 2026: Securing Systems That Write Code and Take Actions

> A practical guide to AI security: the surfaces teams miss, how attackers operate now, governing agents with real access, and what compliance requires.

Three things happened to security at roughly the same time, and most advice still addresses only one of them.

Software started being written faster than anyone could review it. Agents started holding real credentials and taking real actions. And attackers started using the same tools to move faster than the people defending against them.

Those are three different problems. They have different causes, different controls and different failure modes, and a security programme that covers one while ignoring the others is not partially protected. It is unprotected along two axes with good documentation on the third.

This is the working guide to all three.

## Surface one: the code nobody reviewed

A large share of new code is now substantially AI-generated. The interesting question is not whether a model writes less secure code than a person. It is that **code is being produced far faster than the review process that used to catch problems.**

Review was always the real control. Static analysis helps, tests help, but the thing that historically caught a subtle authorisation flaw was a competent engineer reading the diff and asking why. That capacity has not increased. The volume flowing past it has, by a lot.

The failure mode is specific and recognisable. A model produces code that handles the intended path correctly and plausibly, while mishandling the case nobody described: the authorisation check that applies to one endpoint and not its sibling, the input validated on the client and trusted on the server, the tenant identifier taken from the request instead of the session.

That last one is worth dwelling on, because it is the most expensive version of this class of bug and it predates AI. We wrote up how it happens and what it costs in [the costly oversight in multi-tenant SaaS architecture](/blog/costly-oversight-multi-tenant-saas).

The full treatment of securing AI-written software, including what to change about review rather than about generation, is in [your AI wrote the code, who is securing it](/blog/securing-ai-built-apps).

One structural point that gets missed: agents working in your repository do not fix weak engineering practice, they scale it. A codebase without tests, clear boundaries and real review gets worse faster once agents are committing to it, because throughput rises and the guardrails do not. That argument is made in [agents do not fix broken engineering practices](/blog/is-your-codebase-agent-ready).

## Surface two: agents with credentials

An AI agent that can act is, from a security perspective, a service account with unpredictable judgment.

That framing resolves most of the confusion. You already know how to reason about a service account: least privilege, audited access, rotation, monitoring, blast-radius limits. Apply all of it. Then add the parts that are genuinely new.

**Every piece of content an agent reads is untrusted input.** A support ticket, a scraped page, a PDF, an email. If it contains text engineered to look like an instruction, a naive agent will follow it. This is prompt injection, and it is not an exotic research threat, it is the default outcome of feeding an agent arbitrary content without a boundary.

You cannot prompt your way out of it. The defence is architectural: the agent's credentials must make the worst case survivable, irreversible actions must require a human, output must be validated before it reaches a database or an external service, and ingested content must never be treated as a command however confidently it is phrased.

**Governance has to be designed in at the first connection.** The pattern we keep encountering is a team rushing an agent into production for the productivity win and discovering the security bill later, usually at the worst possible moment. Retrofitting least-privilege onto a system that already has broad access is a rewrite, not a configuration change.

The complete version is in [agentic AI security](/blog/agentic-ai-security).

For a worked example of a system built to this shape, the [voice compliance teardown](/services/ai-automation/systems/voice-compliance-knowledge-base) authenticates the caller before the exchange is allowed to become a conversation, and answers strictly from approved documentation or states that it cannot answer. Both are design decisions rather than model capabilities, which is the point.

## Surface three: attackers moved first

The early coverage of AI-enabled attacks focused on better-written phishing emails. That turned out to be the least interesting part.

The change that matters operationally is that **attackers largely stopped breaking in and started logging in.** Intrusions increasingly begin with valid credentials obtained beforehand, which means the intruder looks like a legitimate user from the first request. Perimeter controls do not fire, because nothing was breached. Your detection problem became behavioural.

Where AI genuinely shows up is speed and scale across the rest of the chain: reconnaissance, credential handling, lateral movement, and adapting during an intrusion rather than following a fixed playbook. We went through the published threat mapping in [AI attackers have moved past phishing](/blog/ai-cyber-threats-2026), and the identity-centric picture specifically in [cloud security in 2026](/blog/cloud-security-2026).

The consequence is an arithmetic problem rather than a technology problem. Breakout time, the gap between initial access and lateral movement, is now measured in tens of minutes, with the fastest recorded cases under a minute. Human alert review is measured in hours, because people sleep and queues are long.

A thirty-minute attack against a twelve-hour response loses. That is the whole case for automating detection and response, and it holds without any vendor statistic attached to it.

Which matters, because the category is being sold with a remarkable quantity of invented numbers. We traced three of the most-repeated statistics in the agentic security operations market back to nothing at all, in [the AI SOC is real, most of the numbers sold with it are not](/blog/agentic-soc-2026). The honest version of the argument is stronger than the embellished one, which makes the embellishment doubly annoying.

## What compliance actually requires

Most AI compliance conversations cite the wrong rule.

The pattern is consistent: a team adopts a generic AI compliance checklist, which simultaneously over-restricts things that carry no real obligation and misses the provision that genuinely binds their use case. The checklist feels like diligence and functions as noise.

Healthcare is the clearest example. Teams reflexively cite HIPAA for anything touching patient data, when the provision actually constraining algorithmic decision support is frequently elsewhere, with different requirements and a different enforcement posture. We worked through that specific case in [everyone cites HIPAA for healthcare AI](/blog/healthcare-ai-hipaa-1557).

The general method is unglamorous and it works. Map your actual data flows and actual decisions. Identify which specific provisions govern each. Then engineer against those, rather than against a summary of the regulatory mood. The output is usually fewer controls than the checklist demanded and at least one obligation the checklist entirely omitted.

A related point on cost rather than compliance: AI spend has become a governance surface of its own, because a system that can call models in a loop can also spend in a loop. If you cannot say which features and customers drive your bill, you do not have a cost problem yet, you have a visibility problem that will become one. That is covered in [FinOps for AI](/blog/finops-for-ai).

## The questions a real review asks

Security reviews for AI systems tend to arrive as a generic questionnaire, which produces generic answers. These are the questions that actually separate a system that survives from one that has not been tested yet, grouped by the three surfaces.

**On the agent itself**

What can this agent reach with the credentials it holds right now, as opposed to what it was designed to reach? Answer by reading the permission grant, not the architecture diagram.

If this agent were fully compromised at this moment, what is the worst single action it could take, and is that action reversible? If the answer is not reversible, there should be a human in front of it.

Which content does the agent ingest that a third party controls? Tickets, emails, uploaded documents, scraped pages, webhook payloads. Every one of those is an injection vector and should be treated as data under all circumstances.

Where does the agent write? A model producing a value is harmless. A model producing a value that lands unvalidated in a database, a payment field or an outbound message is the actual risk, and validation belongs between the two.

Can you reconstruct, from logs alone, why the agent took a specific action three weeks ago? If not, you cannot close an incident, only describe it.

**On the code**

Which code paths were generated and merged without a human reading them line by line? Not which repositories use AI, which paths.

Where is authorisation enforced, and is it enforced consistently across sibling endpoints? Inconsistency between neighbouring routes is the single most common flaw we find in fast-moving codebases, AI-assisted or not.

Is the tenant or user identifier taken from the authenticated session, or from something in the request? If it can come from the request anywhere, it will eventually come from the request everywhere.

What automated checks scale with code volume rather than with reviewer attention? That ratio is the control that actually holds as throughput rises.

**On detection**

If a valid credential were used by someone who should not have it, which signal fires? If the honest answer is none, perimeter controls are doing no work against the dominant intrusion pattern.

How long from anomalous behaviour to a human being paged, measured rather than estimated? Compare it against a breakout time measured in tens of minutes and decide whether the gap is acceptable.

What is the rollback for an automated containment action? Isolating a compromised device is excellent. Isolating an executive laptop mid-board-meeting because a heuristic misfired is a different experience, and the difference is whether somebody designed the undo.

**On obligations**

Which specific provisions govern this specific data flow? Not which regulations exist in your sector. Which clauses apply to what you are actually doing.

Who signed off that mapping, and when was it last revisited against what the product now does rather than what it did at launch?

Most of these take minutes to ask and occasionally reveal something that would have taken months to discover the other way.

## What to actually do

If you want a sequence rather than a reading list, this is the order we would run it in.

**Establish what your agents can reach.** Not what they were designed to reach. What the credentials actually permit today. This is usually the most uncomfortable hour of the engagement and the most valuable.

**Put a human on anything irreversible.** Deleting, paying, sending externally, changing permissions. The approval gate costs latency and buys you the ability to survive being wrong.

**Make the agent's decisions reconstructable.** Log the call, the inputs and the reason. An incident you cannot reconstruct is an incident you cannot close.

**Fix the review bottleneck rather than the generator.** The problem is throughput exceeding scrutiny. Add automated checks that scale with volume, and reserve human attention for the code paths where being wrong is expensive.

**Detect on behaviour, not on perimeter.** If intrusions begin with valid credentials, your controls need to notice a legitimate account doing something uncharacteristic. That is a different investment from blocking at the edge.

**Map compliance to provisions, not to vibes.** Once, properly, with someone who reads the actual text.

## The rest of the cluster

**AI systems and agents**

- [Agentic AI security: governing agents before they become your breach](/blog/agentic-ai-security)
- [Your AI wrote the code. Who is securing it?](/blog/securing-ai-built-apps)
- [Agents do not fix broken engineering practices](/blog/is-your-codebase-agent-ready)

**Threat landscape**

- [AI attackers have moved past phishing](/blog/ai-cyber-threats-2026)
- [Cloud security in 2026: attackers log in](/blog/cloud-security-2026)
- [The AI SOC is real, most of the numbers are not](/blog/agentic-soc-2026)

**Architecture and compliance**

- [The costly oversight in multi-tenant SaaS architecture](/blog/costly-oversight-multi-tenant-saas)
- [Everyone cites HIPAA for healthcare AI](/blog/healthcare-ai-hipaa-1557)
- [FinOps for AI](/blog/finops-for-ai)

## Where we come in

The work described above is the substance of our [Security and Compliance](/services/security-compliance) practice: least-privilege design for systems that act, audits of what you have already shipped, and an honest read on where you would actually get hit rather than where a checklist says to look.

If you are running AI in production and are not confident you would notice a valid-looking login doing something it should not, that is the conversation worth having. Tell us what you are running and [book a discovery call](/contact).

_This post is engineering guidance rather than legal advice. For a binding view on your regulatory obligations, consult counsel in the relevant jurisdiction._