AI Governance: When Agent Deployment Outpaces Institutional Control

AI agents are taking on increasingly consequential tasks across enterprise operations. They retrieve information, interact with business systems, invoke external tools and execute workflows that previously required direct human involvement.

As these capabilities expand, organisations face a growing challenge: understanding how their agents behave, whether existing controls remain effective and what evidence they can provide when customers, security teams or insurers question their exposure.

New research from ServiceNow illustrates the scale of this challenge. Published on October 20, 2026, the study found that 90% of surveyed organisations reported an agentic AI security incident during the previous year, while only 13% met its criteria for a defensible security posture.

For companies developing AI applications for institutional customers, these findings have implications beyond internal security. They raise questions about how AI risk is assessed, documented and communicated to the organisations relying on these systems.

What ServiceNow's Research Reveals

ServiceNow's Deployed but Ungoverned: The State of Agentic Security, conducted with Phronesis Partners, surveyed more than 3,700 senior security and technology decision-makers across 20 countries.

The findings reveal several weaknesses in how organisations manage agentic AI:

• 90% reported an agentic AI security incident in the previous year.

• 13% met ServiceNow's criteria for a defensible security posture.

• 29% discovered previously unknown agents operating in production.

• 44% of security teams designed security into agents before development.

• 66% could not respond automatically to anomalous agent behaviour.

• Only 36% of organisations reporting incidents contained them within 24 hours.

These are survey-reported findings, rather than independently verified incident rates. The 13% figure reflects ServiceNow's assessment framework, which considers attack surface, accountability, security by design, visibility and audit readiness.

The research primarily reflects midsize and large organisations, with 97% of respondents representing businesses reporting annual revenue of at least $250 million. Its findings should therefore not be treated as representative of every AI developer or startup.

Nevertheless, the results highlight operational weaknesses that can affect both institutions deploying AI agents and technology companies supplying AI applications to those institutions.

The underlying concern is that agent deployment can expand more quickly than an organisation's ability to understand and control the resulting exposure.

Knowing Which Agents Exist Is Only the Beginning

Effective governance requires an accurate account of which agents are operating, what systems they can access and who is responsible for their activities.

ServiceNow found that 29% of surveyed security teams had discovered previously unknown agents operating in production. Such discoveries indicate potential weaknesses in inventory and oversight, although an unregistered agent is not necessarily unsafe.

For an AI application provider, the challenge can become more complicated as its product evolves. A customer-support agent might initially retrieve information from an approved knowledge base, then later gain access to customer records, payment-related workflows or external tools.

Each integration can change the application's exposure. A system originally designed to provide information may eventually have permission to modify records, initiate actions or interact with sensitive business processes.

Maintaining an accurate inventory and reviewing permissions are important responsibilities for the organisation operating the system. However, these measures alone cannot establish whether an agent will behave appropriately when it encounters manipulated information or conflicting instructions.

An agent may have legitimate access to a tool and still use it in an unintended way. Understanding that possibility requires examining the application's behaviour under conditions that challenge its intended boundaries.

Agent Permissions Cannot Substitute for Behavioural Testing

Consider an AI customer-service agent authorised to retrieve account information and respond to enquiries.

During normal testing, it may perform these tasks correctly. But what happens when a retrieved document contains instructions attempting to redirect the agent? Could a carefully constructed conversation cause it to disclose information outside the intended context? Could an attacker manipulate its use of a connected tool?

These are illustrative risk scenarios, not incidents documented in ServiceNow's study.

They demonstrate a limitation of relying exclusively on functional testing. An agent can successfully complete its intended tasks while remaining vulnerable to manipulated inputs or attempts to override its instructions.

For AI developers, this creates a need to evaluate how applications behave when their instructions, inputs or workflows are deliberately challenged.

AetherLab's AdversarialScan addresses this assessment problem through adversarial testing of defined AI behaviours. Depending on the application and assessment scope, testing can examine direct and indirect prompt injection, instruction overrides, attempts to extract restricted information and misuse of connected capabilities.

The findings should distinguish between an attempted action, an action blocked by existing controls and an action successfully completed.

That distinction matters when developers need to explain their application's actual exposure to an enterprise customer or institutional risk team. It also helps identify whether a vulnerability requires changes to application logic, permissions or other technical safeguards.

Security Assessment Must Continue as Applications Evolve

ServiceNow's research found that only 44% of surveyed security teams designed security into agents before development.

Involving security teams early allows organisations to establish access restrictions, monitoring requirements and expectations for sensitive workflows before an application becomes operational.

However, controls that were effective during initial deployment may need reassessment as the application changes.

An AI agent might gain access to a new tool, begin processing a different category of information or adopt an updated model. These changes can introduce behaviours and vulnerabilities that were not present during earlier testing.

For an AI company serving institutional customers, a previous assessment may therefore provide an incomplete picture of the current application.

A practical approach is to connect reassessment to material changes in the system's capabilities, permissions and operating conditions.

AdversarialScan can provide a point-in-time evaluation of relevant behavioural risks. Where weaknesses are identified, the developer can implement appropriate mitigations and reassess the affected behaviours.

AetherLab's Guardrails can support defined mitigation requirements through configurable policies for supported text and image interactions. Such controls complement application-level permissions, monitoring and security architecture rather than replacing them.

The important consideration is whether a mitigation addresses the behaviour identified during assessment and whether subsequent testing supports that conclusion.

Detecting an Incident Does Not Guarantee Containment

ServiceNow also identified weaknesses in organisations' ability to respond when agents behave unexpectedly.

According to the study, 66% of surveyed organisations could not respond automatically to anomalous agent behaviour. Among organisations reporting incidents, only 36% contained them within 24 hours.

For agents capable of executing connected actions, the time between detecting a problem and containing it can be consequential.

Consider an agent that begins retrieving information outside the scope of a legitimate customer enquiry. Monitoring might detect unusual activity, but containment may require the application to revoke access, suspend a workflow or escalate the activity for human review.

These operational capabilities depend on the organisation's application architecture, access management and incident-response systems.

Adversarial assessment serves a different purpose. It can test whether defined misuse scenarios succeed, whether relevant safeguards prevent them and what vulnerabilities remain.

Those findings can help developers prioritise mitigation and identify behaviours that warrant further testing. They should not be confused with an automated incident-response capability or a guarantee that future incidents will be prevented.

Why Institutional Customers and Insurers Need Better Evidence

The consequences of weak AI governance are not limited to the organisation operating an application.

AI developers serving institutional customers may face security reviews, procurement assessments and requests for technical evidence before their applications are approved for particular business uses.

When an AI application can access sensitive information, interact with financial workflows or perform consequential actions, customers may need more than a description of its intended safeguards.

They may ask which behaviours have been tested, what vulnerabilities were identified, how those vulnerabilities were addressed and whether any material exposure remains.

Similar questions can arise during specialist AI liability and technology risk insurance discussions, depending on the application, policy and underwriting process.

For an AI company preparing for an enterprise security review, responding to a broker's request or approaching an insurance renewal, technical evidence can help explain the risks associated with its application.

For example, an assessment may document whether manipulated instructions caused an agent to reveal restricted information, whether an existing control blocked the attempt and whether remediation changed the observed result.

AetherLab's Evidence Pack helps organise assessment findings, control effectiveness, mitigation information and residual exposure into documentation that relevant stakeholders can examine.

This provides a more informative basis for technical risk discussions than unsupported statements that an application has been tested or is secure.

Such evidence does not establish insurability, determine policy coverage or replace an insurer's underwriting judgement. Its value lies in making the application's assessed behaviour and unresolved risks more transparent.

How AetherLab Supports AI Risk Assessment and Evidence

ServiceNow's findings cover several areas of enterprise AI security, including agent discovery, accountability, security design and incident response.

Addressing those challenges requires multiple capabilities. Agent inventories, identity and access management, operational monitoring and incident-response infrastructure remain responsibilities for the organisations developing and deploying AI systems.

AetherLab focuses on evaluating defined AI risks, supporting appropriate mitigation and documenting the resulting evidence.

AdversarialScan tests how an AI application responds to adversarial inputs and attempts to cross intended behavioural boundaries. This helps identify vulnerabilities that may not appear during normal functional testing.

Guardrails supports defined policy-based mitigations for supported interactions, complementing the application's broader technical safeguards.

Evidence Pack documents observed findings, relevant controls, mitigation actions and remaining exposure. This information can support technical reviews by institutional customers, risk teams and insurance stakeholders.

Together, these capabilities support a practical assessment process: identify relevant behavioural risks, evaluate them under defined conditions, address identified weaknesses and document what the results demonstrate.

The scope and limitations of the assessment remain important. Evidence from one version of an application does not automatically establish the behaviour of every subsequent version or deployment environment.

Institutional Control Must Keep Pace With Agent Deployment

ServiceNow's research illustrates the difficulties organisations face when agent capabilities expand faster than their security oversight and response processes.

For AI developers and deployers, addressing those difficulties involves maintaining accurate information about their systems, evaluating relevant behavioural vulnerabilities and reassessing applications when their capabilities materially change.

For companies facing institutional customer reviews or insurance-related scrutiny, documented findings can also help explain what has been tested, which controls were effective and what exposure remains unresolved.

As AI agents gain greater authority over business workflows, the ability to provide that evidence becomes an important part of institutional AI risk management.

Explore AetherLab's Evidence Pack to learn how documented AI risk assessments can support institutional review and risk evaluation.