AI security is an engineering problem, argues NVIDIA’s chief security officer — and that framing is doing more work than it appears. Writing on 21 September 2026, Saša Zdjelar, who is also head of product security at the company, set out the consequence in one line: “AI security is an engineering problem. That means defined security requirements, enforceable controls, named owners and evidence that protections work.”
Four requirements, each of them mundane by the standards of any other engineering discipline. The uncomfortable part is what happens when you check them against what organisations running agents in production have actually built. A survey of 750 senior technology leaders across the UK and US found that just 7.2% have a named individual with formal accountability for AI agent behaviour. NVIDIA’s third requirement is met by roughly one organisation in fourteen.
This article works through the layered model Zdjelar describes, what each layer is genuinely responsible for, the worked failure case at the centre of the argument, the tooling that has appeared around it, and the survey evidence showing how far current practice sits from the standard. If you are deploying agents against real systems, the gap between those two pictures is your actual risk register.
Table of contents
- Why AI Security Is Framed as Engineering, Not Policy
- The Three Layers Where AI Security Has to Land
- The Worked Example at the Centre of the AI Security Argument
- The AI Security Baseline Every Agent Needs Before It Runs
- The AI Security Evidence Requirement Most Teams Skip
- The Accountability Gap in AI Security
- The AI Security Tooling That Has Appeared Around This
- The Open Secure AI Alliance Behind the Push
- What to Do About AI Security This Quarter
- References
Why AI Security Is Framed as Engineering, Not Policy
The claim is deliberately deflationary. It says this is not a new discipline requiring new theory; it is the old discipline applied under harder conditions.
The AI security fundamentals did not change
Zdjelar’s argument starts from continuity. The internet and cloud computing both changed how software operates while leaving the core responsibilities intact: establish identity, control access, limit exposure, and verify that protections work. AI security inherits all four, unchanged.
What actually changed is the operating conditions
Agents reason, use tools and adapt their actions based on data they encounter. That combination breaks an assumption most controls were written under — that the software’s behaviour is determined by its code rather than by the content it reads. Applying established principles to that condition is the work.
Why “engineering problem” is a demand, not a reassurance
Calling something an engineering problem sounds like a downgrade in difficulty. It is not. It commits you to written requirements, controls someone can point at, an accountable name and test results — four things that are easy to describe and expensive to produce. Most of the AI security gap documented below is a gap in exactly those artefacts.
The pressure that produces the gap
The same survey found 81% of respondents feel pressure to deploy agents quickly, with 25.8% describing that pressure as significant. Organisations want the productivity while the practices to govern these systems are still being written, which is precisely the condition Zdjelar names.
The Three Layers Where AI Security Has to Land
The model is simple enough to hold in your head, which is the point of it.
Layer one: models provide capabilities
The model is the reasoning engine. It decides what to attempt. It is also the layer where most AI security attention has historically been concentrated — alignment, refusals, guardrails on output — and the layer least able to enforce anything on its own.
Layer two: harnesses organise context, tools and workflows
The harness is what assembles the prompt, decides which tools are available, and sequences the workflow. It determines what data reaches the model and what the model is able to invoke. Skills, plugins and tool definitions all live here, which makes supply-chain integrity a harness-layer problem.
Layer three: runtimes execute, and carry the hardest AI security duty
The runtime is where actions actually execute: file access, network destinations, processes. Zdjelar’s key claim is that this layer must install its limits “independently of the agent’s reasoning” — the environment where an agent runs determines what it is allowed to do, whatever the agent concludes it should do.
AI security controls have to span all three layers
Data, instructions and actions move through the whole stack, so no single layer can carry the AI security burden. A guardrail at the model layer does not stop a tool call; a policy at the runtime does not stop a poisoned skill being loaded. The controls have to be layered because the failure paths are.
| Layer | What it does | What it must enforce | Failure if it does not |
|---|---|---|---|
| Model | Reasons, decides what to attempt | Behavioural guidance and refusals | Agent attempts harmful actions |
| Harness | Assembles context, tools, workflow | Tool and skill provenance, scope of context | Poisoned skills and untrusted instructions load |
| Runtime | Executes actions against real systems | Files, network destinations, processes | A wrong decision becomes a real action |
| Identity and policy | Says who the agent is and what it may do | Task-scoped credentials, approval gates | Permission creep and unattributable actions |
| Logging | Records what was attempted and allowed | Protected, tamper-resistant records | Incidents cannot be reconstructed |
The Worked Example at the Centre of the AI Security Argument
Zdjelar’s illustration is worth walking through slowly, because every control in the model has a job in it.
The scenario
An agent is updating a customer record. In an attached document it encounters malicious instructions, and it attempts to export customer data to an unauthorised destination. Nothing exotic: a legitimate task, a hostile input, and an action the agent believes it should take.
What should stop it
A network policy should block the transfer. That is a runtime control, and it works regardless of what the model concluded. This is the practical meaning of a boundary that holds “even when an agent makes the wrong decision” — the control does not consult the agent’s reasoning.
What should record it
Protected logs should capture the attempted tool call, the authorisation decision and the outcome, so that the security team can identify the tool used and the destination it tried to reach. Without that record the organisation learns nothing from an attack it successfully survived.
The permission principle underneath
The deeper rule is that permission to update a customer record should not automatically extend to exporting that data. An agent can request additional access, but it cannot authorise that access itself. Separating those two capabilities is the difference between a contained incident and a breach.
Why guardrails alone are not AI security
Instructions and safeguards help guide behaviour, and they are worth having. But guidance is not enforcement, and an agent that has been persuaded by hostile input is precisely the case where guidance has already failed. That is the argument for spending on runtime boundaries rather than only on prompts.
The AI Security Baseline Every Agent Needs Before It Runs
The requirements list is short, and most of it is ordinary access management applied to a non-human actor.
Traceable identity and task-scoped credentials
Each agent needs its own identity and credentials limited to its assigned task. Shared service accounts across a fleet of agents destroy attribution, which is the quiet way AI security fails in practice, and they turn every incident into a forensic problem. In the survey, 91.2% of organisations said they were at least somewhat prepared to manage agents as authenticated users — but only 30.4% called themselves very prepared.
Written AI security policies about access, change and approval
Organisations need clear policies defining what information agents can access, which systems they can change and which actions require approval. Within those boundaries, consequential actions and permission changes still require human approval — the agent proposes, a person disposes.
Verified tools, skills and dependencies
Teams also need to verify the source and integrity of the tools, skills and dependencies their agents use. This is conventional software supply-chain cybersecurity pointed at a new class of artefact, and it belongs in the AI security budget rather than beside it, and it is the reason package-analysis tooling shows up in agent security discussions at all.
Revocation and containment procedures
Protected records only help if someone can act on them. Clear procedures for revoking access and containing incidents are what make the evidence actionable, and they are the least glamorous item on the list.
The AI Security Evidence Requirement Most Teams Skip
The fourth of Zdjelar’s requirements — evidence that protections work — is where the framing becomes demanding.
Test AI security controls before deployment, against specific attempts
Before deployment, teams need evidence that controls block attempts to obtain credentials beyond an agent’s scope, or to send sensitive data to an unauthorised destination. Note the shape: not “the agent behaved well in testing” but “the control blocked the attempt”.
Test the monitoring itself
Testing should also cover attempts to change permissions or to interfere with monitoring. An agent that can quietly disable its own logging is a much worse problem than one that attempts a blocked action, and it is the case least likely to be covered by a standard evaluation suite.
Retest after material changes
Because models, tools and workflows all change independently, the tests have to be repeated after any material change to any of them. A swap of the underlying model is a change to the security posture of every workflow built on it.
Findings become permanent AI security tests
Failures discovered in testing or in operation should be reproduced, investigated and addressed — and each finding should then become a repeatable test, so future releases can be checked against it. This is regression testing applied to AI security, and it is the mechanism that stops the same failure recurring.
A named owner signs it off
Someone has to use those results to decide whether the system is ready to deploy, and to ensure failed tests lead to corrective action. Which brings us to the number that undermines everything above.
The Accountability Gap in AI Security
The survey behind these figures covered 750 senior technology leaders in the UK and United States across financial services, healthcare, telecoms, manufacturing and travel, in two waves in December 2025 and April 2026.
Only 7.2% have a named owner
Just 7.2% of organisations have a named individual with formal accountability for AI agent behaviour. Another 29.9% describe responsibility as shared but not formally defined, and 32.4% call it unclear or situation-dependent. The report’s summary is that 85% have no formal accountability at all.
Half the fleet is running unmonitored
The report puts 48% of AI agents in production as running unsecured, with mean monitoring coverage around 52% — barely moved from 46.96% in the December wave. Only 9.5% of organisations secure more than 81% of their deployed agents, and 90% have unmonitored agents in production.
Incidents are already common
54% of organisations have already suffered a security incident involving agents: 34.9% confirmed and 19.1% suspected. Given the monitoring coverage figures above, the suspected category deserves attention — you cannot confirm what you were not watching.
Confidence moved in the wrong direction
The most telling pair of numbers: confidence in visibility rose from 82.6% to 91.8% between the two waves, a nine-point increase, while actual monitoring coverage stayed flat and agent estates roughly doubled in four months. Belief in control improved while control did not.
Agent estates are growing faster than AI security controls
38% of organisations now run more than 100 agents, with the most common deployment bracket moving from 26–50 to 76–100 in four months, and 81.7% planning to deploy more within a year. Every one of those agents is an identity, a set of credentials and a set of possible actions.
| The requirement | What the survey measured | Gap |
|---|---|---|
| Defined security requirements | 19.7% say all agents are fully secured pre-deployment | Four in five ship without it |
| Enforceable controls | No single control used by even 40% of organisations | No common baseline exists |
| Named owners | 7.2% have a formally accountable individual | The largest gap of the four |
| Evidence protections work | 48% of production agents running unsecured | Half the estate produces no evidence |
| Regulatory cover | 39.5% believe current regulation is sufficient | No external forcing function yet |
The AI Security Tooling That Has Appeared Around This
A year ago this conversation was mostly abstract. It is now a product category, which is itself evidence the AI security problem is being treated as engineering.
A runtime that sits outside the agent’s reach
NVIDIA OpenShell is an open-source secure runtime that enforces policies outside the agent’s reach and provides sandboxed execution, governing how agents access data, network and system resources. The design principle matters more than the product: the enforcement point is somewhere the agent cannot influence.
Governance and skill verification built on top
Partners are building on that base. Cisco’s DefenseClaw adds a governance layer, and JFrog integrates with OpenShell to scan and verify agent skills and to enforce which skills agents can access. That last capability is the harness-layer supply-chain control the model calls for.
Continuous adversarial AI security testing
For the evidence requirement, the named examples are CrowdStrike’s SafeMind, which strengthens defences through repeated attack simulations, and Palo Alto Networks’ Prisma AIRS for continuous red teaming as models and applications change. Both are pitched at the retest-after-change problem rather than at one-off assessment.
Investigation tooling for AI security teams
For incident work the examples are Capital One’s VulnHunter for AI-powered code security and ReversingLabs’ Spectra Assure for analysing software packages to detect malware and tampering. Capable AI can help find vulnerabilities, validate fixes and investigate attacks — and Zdjelar is specific that its value should be judged on reproducible findings, verifiable fixes and measurably faster response.
Why open models matter during an incident
The argument for open models here is operational rather than ideological. Closed models offer managed capabilities; open ones let defenders inspect components, adapt strategies and work on infrastructure they control. During an incident that control lets a team reproduce a failure and test a fix against its own systems while keeping sensitive evidence inside its own environment.
| Named tool | Organisation | Layer it addresses |
|---|---|---|
| OpenShell | NVIDIA | Runtime: sandboxed execution and policy enforcement |
| DefenseClaw | Cisco | Governance layer above the runtime |
| Skill scanning integration | JFrog | Harness: verifying and gating agent skills |
| SafeMind | CrowdStrike | Evidence: repeated attack simulation |
| Prisma AIRS | Palo Alto Networks | Evidence: continuous red teaming |
| VulnHunter | Capital One | Investigation: AI-assisted code security |
| Spectra Assure | ReversingLabs | Supply chain: package malware and tampering |
The Open Secure AI Alliance Behind the Push
The collaborative vehicle for all of this launched two months before the piece that describes it.
More than 100 organisations from day one
NVIDIA co-founded the Open Secure AI Alliance on 27 July 2026, and it launched with more than 100 inaugural partner organisations rather than building up to that number. Its stated aim is to “ensure defenders everywhere have open, frontier tools they can trust and control”, and NVIDIA’s own contribution is open models, model weights, data and agent harness research.
Who is in it
Named participants include Microsoft, Amazon, IBM, Intel, Red Hat, Cisco, CrowdStrike, Palo Alto Networks, Hugging Face, Mistral, Mozilla, GitHub, Elastic, Snowflake, Databricks, Adobe, HPE, Salesforce and ServiceNow. That is a broad enough coalition across cloud, security, enterprise software and AI research that the interoperability argument has weight behind it.
What sharing is supposed to achieve
The stated purpose is to shift the advantage toward defenders: sharing evidence of what failed, which controls worked and how fixes were verified helps other teams strengthen their own systems. Whether that materialises depends on whether members publish failures as readily as they publish products.
What to Do About AI Security This Quarter
None of this requires waiting for a standard to settle.
Start with the name, not the AI security tooling
The cheapest of NVIDIA’s four requirements is the one 92.8% of organisations have not met. Write down who is accountable for each agent’s behaviour, and give that person authority to block a deployment. It costs nothing and it is the precondition for the other three meaning anything.
Inventory your agents before you buy AI security tooling
With 90% of organisations reporting unmonitored agents in production and estates doubling in four months, the first technical task is an inventory: which agents exist, whose credentials they hold, and what they can reach. Our coverage of agent access permissions goes into how narrowly those grants can reasonably be scoped.
Put the boundary where the agent cannot reach it
Whatever you buy, apply the single structural test in Zdjelar’s argument: can the agent influence the control? If the enforcement lives inside the harness the agent runs in, it is guidance. If it lives in the runtime or the network, it is a boundary.
Make monitoring adversarial, not just observational
Watching agents is not the same as testing whether the watching survives contact with an attacker. The emerging approach of using automated systems to monitor other agents, which we examined in the case for monitoring rogue agents, only helps if the monitors are themselves inside a boundary the monitored agent cannot cross.
Treat vendor AI security self-assessment sceptically
The AI security tooling market is now crowded with vendors assessing their own products, a tension we looked at in our piece on in-house auditors at AI labs. Ask for the failed tests, not the passed ones — a supplier that cannot show you a finding it fixed has probably not looked hard.
References
AI Security Is an Engineering Problem — How to Solve It at Every Layer of the Agent Stack
State of AI Agent Security Report 2026 — Gravitee
Industry Leaders Join Open Secure AI Alliance for AI Safety and Security
Open Secure AI Alliance Next Steps — NVIDIA
Where Security Fits in an AI Agent Stack — NVIDIA Technical Blog
Emerging Security Practices for AI Agents — Frontier Model Forum
Prompt injection still drives most agentic AI security failures in production
Indirect Prompt Injection in the Wild — Cloud Security Alliance
Nvidia and partners launch Open Secure AI Alliance for better security
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.