AI security trends show adoption outpacing governance controls

At a glance

What this is: This is a market overview of AI security trends that argues adoption, regulation, and threat pressure are outrunning organisational readiness.

Why it matters: It matters because identity, access, data, and governance teams now have to shape controls for AI use across human, NHI, and emerging agentic contexts before shadow AI becomes normalised.

By the numbers:

• 49% of firms use tools like ChatGPT across departments, from IT and marketing to finance and customer service.
• 77% of organizations find themselves unprepared to defend against AI threats.
• 90% of organizations are actively implementing or planning to explore large language model use cases.
• Only 5% feel highly confident in their AI security preparedness.

👉 Read Lakera's AI security trends report for the market data and adoption signals

Context

AI security is no longer a narrow model-safety problem. It is an identity and governance problem because the same systems that can generate content, answer questions, and assist workflows are now being allowed into business processes without mature control boundaries. That creates exposure across human access, non-human credentials, and the decision paths that will increasingly be delegated to AI systems.

The central gap is not whether organisations are experimenting with AI. It is whether they can define, observe, and enforce what those systems are allowed to access, which data they can consume, and which actions they can take. For IAM, NHI, and security architecture teams, that makes AI security a control-plane issue rather than a purely model-specific one.

Key questions

Q: How should security teams govern AI tools that are spreading across departments?

A: Security teams should govern AI tools the same way they govern other access-bearing systems: by defining owners, approved data classes, identity bindings, and audit points. The goal is not to stop adoption, but to keep AI use inside enforceable boundaries. If the organisation cannot show who approved access and what data the tool can touch, the governance model is incomplete.

Q: Why do AI tools create new identity and access risks?

A: AI tools create identity risk because they often sit between users and sensitive systems, which lets them inherit permissions, reuse credentials, and process data at scale. That means the control failure is rarely the model alone. It is usually the combination of broad access, weak lifecycle ownership, and unclear policy enforcement around the AI layer.

Q: How do organisations know whether AI security controls are actually working?

A: They know controls are working when every AI system has a documented owner, approved data scope, monitored access path, and a revocation process that can be tested. Adoption counts, policy documents, and confidence surveys are not enough. The real signal is whether the organisation can prove that AI access is limited, logged, and recoverable.

Q: What should teams do when AI use is already happening before policy is ready?

A: Teams should first identify the highest-risk AI use cases, especially those touching sensitive data or production systems, and then apply immediate restrictions to access, retention, and credential reuse. Parallel to that, they should build a lifecycle model for approval, review, and offboarding. Waiting for a perfect policy creates more exposure than controlled interruption.

Technical breakdown

Why AI security is really an identity governance problem

AI systems become security-relevant when they are placed inside business workflows that depend on credentials, data permissions, and execution boundaries. The risk is not just prompt abuse. It is that the AI layer often sits on top of existing identities, service accounts, APIs, and policy exceptions, which means any weakness in identity lifecycle, secrets handling, or authorisation scope becomes easier to exploit. In practice, AI security inherits the control failures already present in IAM and NHI environments, then amplifies them through speed and reach.

Practical implication: treat AI governance as an access and entitlement design problem, not a model-only review.

How shadow AI changes the control surface

Shadow AI appears when employees or teams use AI tools, integrations, or embedded assistants without central approval or visibility. That matters because the organisation then loses sight of which data is entering those systems, which credentials are being reused, and whether the resulting outputs are being trusted operationally. This is the same governance failure pattern seen in unmanaged NHIs, but with a broader blast radius because the system may also make recommendations, generate code, or trigger downstream actions.

Practical implication: inventory AI use the same way you inventory other unmanaged identities and secrets.

Where regulation and operational reality are colliding

AI regulation is increasing, but regulation alone does not create enforceable technical controls. Organisations still need practical mechanisms for data restriction, auditability, approvals, and lifecycle management across the tools and identities that support AI use. The operational challenge is that AI adoption is often distributed across departments, so compliance obligations, acceptable-use policies, and identity controls can drift apart unless they are tied back to one governance model.

Practical implication: align policy, data access, and identity ownership before AI use becomes embedded in core business processes.

Threat narrative

Attacker objective: The objective is to exploit AI adoption and weak governance boundaries to reach sensitive data, trusted workflows, or downstream decisions.

1. Entry occurs when AI tools are adopted across departments without central governance, creating an unmanaged access surface for prompts, data, and integrations.
2. Escalation happens when those tools are connected to sensitive systems or reused credentials, allowing the AI layer to inherit more privilege than intended.
3. Impact follows when AI-generated outputs, data exposure, or AI-assisted workflows produce privacy, compliance, or operational failures at enterprise scale.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security has become an identity governance problem before it becomes a model-security problem. The article’s data points show broad adoption and weak confidence, which means the control gap is structural rather than isolated. When AI is embedded in business workflows, the relevant questions become who can access what, which secrets the system can touch, and how those privileges are governed. Practitioners should stop treating AI as a separate security island and manage it through identity, data, and lifecycle controls.

Shadow AI is the new unmanaged identity class. Once departments can adopt AI tools independently, organisations lose the same visibility problems that make unmanaged NHIs risky, only faster and across more business functions. The named concept here is AI trust drift: the gap between where AI is allowed to operate and where the organisation can actually observe and constrain it. The implication is that governance breaks down when access becomes informal before policy catches up.

The market signal is not just rising concern, but rising dependency on AI without matching governance maturity. If 90% of organisations are pursuing LLM use cases while only 5% feel highly confident in preparedness, then the category is moving into operational dependency faster than it is building control discipline. That makes entitlement review, data minimisation, and lifecycle ownership immediate programme issues. Practitioners should assume AI usage will keep expanding and design controls for distributed adoption, not centralised pilots.

AI regulation will not close the gap unless identity teams translate policy into enforceable access decisions. The article points to growing regulation and company-level restrictions, but those measures only work when they are tied to identities, permissions, and monitoring. This is where IAM, NHI, and security operations converge. The implication for practitioners is to connect governance intent to technical enforcement, or accept that policy will remain aspirational.

Security confidence is being overstated relative to actual readiness. The combination of broad use, low confidence, and rapid threat evolution suggests many organisations are confusing experimentation with control maturity. That is especially dangerous when AI systems are allowed to read, summarise, or act on sensitive information. Practitioners should measure AI security readiness by enforceable boundaries, not by the number of tools in use.

From our research:

• 49% of firms use tools like ChatGPT across departments, from IT and marketing to finance and customer service, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For teams thinking ahead on governance design, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next reference point for ownership, rotation, and offboarding.

What this signals

AI trust drift: when use spreads faster than governance, the organisation starts relying on systems it cannot fully inventory or explain. That is the point at which identity teams need to bring AI usage into the same operating model they use for secrets, access reviews, and lifecycle ownership.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive information patterns from codebases, the governance problem extends beyond access control into data handling discipline. Teams should treat AI inputs and outputs as controlled security surfaces, not informal productivity channels.

The practical direction of travel is clear: AI programmes need the same kinds of ownership, review, and control evidence that mature NHI programmes require. For a broader control model, the NIST Cybersecurity Framework 2.0 remains a useful way to connect govern, protect, detect, and respond activities to AI usage.

For practitioners

• Inventory all AI-enabled tools and integrations Build a register of sanctioned and unsanctioned AI systems, including department-owned copilots, embedded assistants, and third-party plugins. Map each system to the data it can access, the identities it uses, and the approvals that created that access.
• Bind AI access to identity lifecycle ownership Assign a named owner for every AI-facing credential, service account, or integration token so renewals, revocation, and access reviews do not drift into ambiguity. Treat AI access like any other non-human entitlement with an accountable lifecycle.
• Constrain data inputs before expanding AI usage Define which data classes can enter AI tools and block sensitive content by default until the organisation can prove logging, retention, and policy enforcement are working. Data restrictions should be enforceable, not advisory.
• Review AI connected secrets and delegated access paths Trace which API keys, tokens, and service accounts are being reused by AI workflows, then reduce standing access wherever the workflow does not require persistent privilege. Focus first on the highest-value business processes and shared credentials.
• Measure readiness by control evidence, not adoption volume Track whether AI systems are covered by access reviews, monitored for abnormal usage, and tied to incident response playbooks. Adoption metrics alone do not show whether governance is real.

Key takeaways

• AI security is now an identity governance issue because broad adoption creates access, data, and ownership risks that model-focused controls do not solve.
• The evidence points to a readiness gap, with widespread AI use and low confidence in existing defences moving in opposite directions.
• Practitioners should anchor AI governance in identity lifecycle, data restriction, and measurable control evidence rather than adoption metrics.

Key terms

• Shadow AI: AI tools, assistants, or integrations used without formal approval or central visibility. In practice, shadow AI becomes an identity and data governance problem because the organisation cannot reliably track what information is entering the system, which credentials are in play, or what downstream actions are being influenced.
• AI trust drift: The gradual gap between where AI systems are allowed to operate and where the organisation can actually observe and constrain them. It typically appears when adoption spreads faster than policy, logging, ownership, or access review processes, leaving security teams with partial visibility and inconsistent enforcement.
• Identity lifecycle ownership: The assignment of clear accountability for creating, reviewing, rotating, and revoking access tied to a specific identity or integration. For AI-enabled environments, this includes humans, service accounts, tokens, and any delegated access paths that support the system’s operation.
• Delegated AI access: Access granted to an AI system through underlying identities such as APIs, service accounts, or tokens rather than through a standalone human login. The security risk is that the AI layer may operate inside a privilege envelope that was never designed for its data access patterns or runtime behaviour.

What's in the full article

Lakera's full article covers the market data and implementation examples this post intentionally leaves for the source:

• Survey details on how organisations are using GenAI across departments and what that means for AI policy design
• The article's comparative statistics on confidence, regulation, and adoption that help frame board-level discussions
• Examples of security concerns, including AI-powered attacks, data exposure, and model misuse, that are useful for programme prioritisation
• The vendor's own practical guidance on how readers can think about securing GenAI workflows and user-facing AI output

👉 Lakera's full article adds the survey numbers, security concern breakdown, and adoption context behind the trend analysis.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.