AI Security in 2026: Securing Systems That Write Code and Take Actions
AI created three security surfaces at once: code written faster than it can be reviewed, agents holding real credentials, and attackers using the same tools you are. Most security advice addresses one and ignores the other two. This is the working guide to all three, plus what the compliance picture actually requires rather than what the vendor deck claims.
IrenicTech · · 9 min read
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.
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.
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.
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.
For a worked example of a system built to this shape, the voice compliance teardown 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, and the identity-centric picture specifically in cloud security in 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. 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.
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.
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
- Your AI wrote the code. Who is securing it?
- Agents do not fix broken engineering practices
Threat landscape
- AI attackers have moved past phishing
- Cloud security in 2026: attackers log in
- The AI SOC is real, most of the numbers are not
Architecture and compliance
- The costly oversight in multi-tenant SaaS architecture
- Everyone cites HIPAA for healthcare AI
- FinOps for AI
Where we come in
The work described above is the substance of our Security and 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.
This post is engineering guidance rather than legal advice. For a binding view on your regulatory obligations, consult counsel in the relevant jurisdiction.
Frequently asked
What is AI security?
AI security covers three related but distinct problems. First, securing software that was substantially written by AI, where the volume of code now exceeds the human review capacity that used to catch flaws. Second, securing AI systems themselves, particularly agents that hold credentials and can take real actions in your infrastructure. Third, defending against attackers who use AI to operate faster and at larger scale than before. A programme that addresses only one of the three leaves the other two open, and in our experience most do exactly that.
What is prompt injection and how do you prevent it?
Prompt injection is when content an AI system reads is crafted to be interpreted as an instruction rather than as data. A support ticket, a web page, a PDF or an email can all carry text that tells an agent to ignore its rules, exfiltrate data or call a tool it should not. The defence is architectural rather than clever wording: treat every piece of model-readable content as untrusted input, scope the agent's credentials so the worst case is survivable, require human approval for irreversible actions, and validate the agent's output before it reaches a database or an external system. You cannot prompt your way out of prompt injection.
Is AI-generated code less secure than human-written code?
The more useful framing is that AI-generated code is not reviewed at the same rate it is produced. A model will reproduce insecure patterns it learned, miss context about your threat model, and generate plausible code that handles the happy path while quietly mishandling authorisation or input validation. None of that is new as a class of flaw. What is new is the volume, which overwhelms the review process that used to be the real control. The fix is to strengthen the control rather than to blame the generator.
How do attackers use AI in 2026?
Less for writing better phishing emails than the early coverage suggested, and more for speed and scale across the rest of the chain: reconnaissance, credential handling, lateral movement and adapting to defences during an intrusion. The pattern that matters most operationally is that intrusions increasingly begin with valid credentials rather than an exploit, so the intruder looks like a legitimate user from the first moment. That makes perimeter controls close to irrelevant and behavioural detection close to essential.
How fast do you need to detect an intrusion?
Faster than your team can currently manage without automation, which is the entire argument. Published threat research puts average breakout time, the gap between initial access and lateral movement, in the region of half an hour, with the fastest recorded cases under a minute. Human alert review typically takes hours, because people sleep and queues are long. A thirty-minute attack against a twelve-hour response is a loss on arithmetic alone, independent of any vendor's claimed statistics.
What compliance rules apply to AI systems?
It depends entirely on what the system does and who it touches, and most public discussion cites the wrong rule. In healthcare, for instance, teams reflexively cite HIPAA when the provision that actually constrains algorithmic decision support is often elsewhere. The practical approach is to map your specific data flows and decisions to the specific provisions that govern them, rather than adopting a generic AI compliance checklist, because the generic version simultaneously over-restricts harmless things and misses the obligation that genuinely binds you.
How do you secure an AI agent that has access to production systems?
Design the governance at the first connection rather than after the agent becomes load-bearing. Scope credentials to exactly the operations needed and nothing adjacent, so a compromise is survivable. Put a human approval gate on anything irreversible, high-value or externally visible. Log every tool call with its reason so an incident is reconstructable. Validate output before it is written anywhere. Treat all ingested content as data rather than instruction. None of this is exotic, and the reason it gets skipped is that it slows the demo down.
Read us on Google
Make IrenicTech a preferred source.
Tell Google you want our work first. It takes one tap, and IrenicTech is favoured in your Top Stories, AI Mode, and AI Overviews whenever you search the topics we write about.
Add to preferred sources
