AI adoption is outpacing security governance models

At a glance

What this is: This is a statistics-led overview of 2023 AI adoption trends, with the central finding that organisations are embedding AI into business and security workflows faster than governance models are adapting.

Why it matters: It matters to IAM and security practitioners because AI systems, assistants, and automated workflows introduce new access, oversight, and accountability questions that overlap with human identity, NHI governance, and broader security control design.

By the numbers:

• According to the research, 27% of senior executives say they are considering or already investing in AI-powered cybersecurity and NLP technologies.
• The 64% of companies believe AI will play a fundamental role in improving overall productivity.
• According to research, AI is already used in more than 75% of network security solutions in the global enterprise landscape.

👉 Read GlobalSign's statistics roundup on 2023 AI adoption and security trends

Context

AI adoption has moved from experimentation into routine business operations, which means the governance problem is no longer limited to model performance or user productivity. The harder question is how organisations assign access, control, and accountability when AI systems begin supporting customer work, analysis, and security operations.

For identity and security teams, the issue is not just the model. It is the account, API key, service principal, token, or workflow that lets the model act, retrieve data, or influence decisions. That creates an identity governance problem that overlaps human identity, NHI, and AI security, even when the article itself is framed as a broad AI trend summary.

Key questions

Q: How should security teams govern AI workflows that use service accounts and API keys?

A: They should treat each workflow as a governed identity, not as a standalone model. Assign an owner, scope the data and actions it can reach, log every connector and token it uses, and revoke access as soon as the workflow changes purpose. If the identity is not documented, the workflow is not governable.

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

A: Because the tool itself rarely acts alone. It relies on credentials, delegated permissions, and data connectors that can exceed the task it was meant to perform. Once those identities are over-scoped, AI becomes a fast route to data exposure or unauthorised action rather than a controlled assistant.

Q: What breaks when AI governance is separated from IAM?

A: Ownership becomes fragmented and revocation becomes slow. Security teams may manage the model, while another team manages the credentials, and neither sees the full access path. That split leaves unreviewed connectors, dormant tokens, and unclear accountability for decisions the AI system can influence.

Q: Which controls matter most when AI is used in security operations?

A: Prioritise identity scope, logging, and approval boundaries. AI-assisted triage can improve response speed, but actions that change containment, access, or configuration should remain reviewable by a human. The control goal is to preserve auditable decision chains, not to remove judgement from the loop.

Technical breakdown

AI adoption creates an access control problem, not just a productivity problem

When organisations deploy AI into business workflows, the security question shifts from whether the model works to what it can reach. AI tools often sit behind API keys, service accounts, delegated permissions, and data connectors that determine which systems they can query or modify. That makes the control plane as important as the model itself. If those identities are over-scoped, the AI layer can become an amplifier for data exposure, policy drift, and untracked automation. In practice, the model may be the visible risk, but the underlying problem is usually access design.

Practical implication: treat AI deployments as identity-bound systems and review every credential, connector, and privilege path before production use.

Security teams are using AI inside detection and response workflows

The article points to AI already being embedded in network security and response use cases. In operational terms, that means AI may assist with pattern recognition, triage, and alert handling, but it also inherits the same trust, provenance, and audit requirements as any other automation layer. If an AI system influences security outcomes, teams need to know what data it sees, what actions it can recommend or execute, and how those outputs are validated. Otherwise, AI can accelerate both good decisions and bad ones at machine speed.

Practical implication: define approval boundaries for AI-assisted security workflows and retain human review for actions with containment or access consequences.

AI productivity claims create governance debt if ownership is unclear

Productivity gains are often used to justify rapid AI rollout, but the governance cost appears later if ownership, data boundaries, and exception handling are not documented. In identity terms, this is similar to allowing ephemeral access without lifecycle control: the system becomes useful faster than it becomes governable. AI governance must therefore include accountability for configuration, data exposure, model updates, and the identities that operate the surrounding workflow. Without that, the organisation gains speed while losing traceability.

Practical implication: assign named owners for AI workflows, data sources, and credentials so the governance model grows with the deployment.

Threat narrative

Attacker objective: The attacker objective is to abuse trusted AI-connected identities and workflows to reach data, influence decisions, or extend access beyond intended boundaries.

1. Entry occurs when AI tools are introduced through permissive integrations, exposed APIs, or unreviewed workflow connectors that grant access to business data and security systems.
2. Escalation follows when the AI-related service account, token, or delegated identity is allowed broader reach than the task actually requires, creating an over-privileged automation path.
3. Impact appears as data exposure, flawed security decisions, or unauthorised actions executed at scale through the AI-enabled workflow.

NHI Mgmt Group analysis

AI adoption is creating identity governance debt faster than most programmes can absorb. The article’s numbers show scale, but the real issue is control drift: AI tools are being inserted into workflows before owners have defined access boundaries, data scope, and audit expectations. That is not a model-quality problem alone, it is a governance problem across IAM, NHI, and AI operations. Practitioners should treat every AI workflow as an identity-bearing system from day one.

AI security is now an access design discipline. When AI is embedded in security operations, customer support, or analytics, the relevant question is which identities make the action possible. Service accounts, API keys, and delegated tokens define what the system can do, and those identities need lifecycle control, least privilege, and revocation discipline. The field should stop discussing AI as a standalone capability and start treating it as a governed access layer. Practitioners should map AI permissions with the same rigour used for privileged human access.

AI productivity claims will keep accelerating adoption, but speed without accountability creates shadow automation. The article shows that organisations want efficiency gains, yet those gains can hide unreviewed workflows, loosely owned connectors, and unclear exception handling. That pattern is especially dangerous where AI outputs can trigger downstream operational changes. The named concept here is shadow automation: AI-enabled workflows that influence business or security actions without a clear owner, control boundary, or revocation path. Practitioners should inventory it before it becomes institutionalised.

Security organisations that deploy AI inside detection and response must preserve evidentiary trust. If AI helps triage alerts or recommend containment, the organisation still needs explainability, traceability, and reviewable decision chains. Otherwise, AI output becomes operational folklore instead of a control input. This is where AI governance intersects with resilience and SOC practice, because speed is only useful when decisions remain auditable. Practitioners should insist on human-verifiable outputs for any AI system that can change security posture.

The broad AI market story is increasingly an identity story in disguise. The biggest risk is not that AI exists, but that AI systems are granted access, trust, and influence without the lifecycle controls normally applied to privileged accounts. That means this category is converging with NHI governance, even when vendors or business teams describe it in productivity terms. Practitioners should align AI governance with identity governance rather than building a separate control universe.

What this signals

Shadow automation is the operating risk that follows from rapid AI adoption: once a workflow has a service account, token, or connector, it can outlive the review process that authorised it. That is why AI governance must converge with NHI lifecycle management, access review, and secrets handling rather than sit beside them as a separate programme.

The programme signal for IAM teams is clear. As AI becomes embedded in analytics, support, and security operations, identity teams will be asked to govern not only human users but also machine-mediated decisions and the identities behind them. That calls for tighter ownership models, shorter credential lifetimes, and more disciplined logging across the AI control plane.

Security leaders should expect pressure to prove that AI outputs are both useful and auditable. If the organisation cannot trace which identity, data source, and workflow produced a decision, it will struggle to defend the control in incident reviews or compliance checks. That creates a practical case for aligning AI rollout with identity governance from the start.

For practitioners

• Inventory every AI-connected identity Catalogue service accounts, API keys, tokens, delegated permissions, and connector accounts used by AI tools across production and test environments. Record the systems each identity can read, write, or trigger so hidden overreach is visible.
• Apply least privilege to AI workflows Reduce connector scope to the minimum data set and action set required for each use case. Review whether the workflow can function with read-only access, scoped datasets, or isolated sandboxes instead of broad platform permissions.
• Define approval points for AI-assisted actions Require human approval for AI outputs that can change access, terminate sessions, modify records, or trigger security response. Keep logs that show which prompt, dataset, and identity path produced the action.
• Establish revocation and rotation for AI credentials Treat AI service credentials as operational secrets with ownership, expiry, and revocation paths. Rotate keys on a defined schedule and remove dormant connectors when a workflow is retired or repurposed.
• Separate experimentation from production governance Use isolated environments for AI pilots and prohibit direct connections to sensitive systems until access reviews, data handling rules, and logging requirements are approved. This prevents shadow automation from becoming the default operating model.

Key takeaways

• AI adoption is creating governance pressure because every useful workflow depends on credentials, permissions, and data access.
• The scale indicators point to rapid deployment, but the control gap remains in ownership, revocation, and auditability.
• Practitioners should govern AI as an identity-bearing system, with least privilege and lifecycle control applied to every connected account.

Key terms

• Shadow Automation: AI-enabled workflows that influence business or security actions without clear ownership, documented access boundaries, or a reliable revocation path. The risk is not just automation itself, but automation that outlives the governance process meant to control it.
• AI-Connected Identity: A service account, token, API key, or delegated permission that allows an AI system to read data, call tools, or trigger downstream actions. These identities must be governed like other privileged machine identities because they define the system's real power.
• Governance Debt: The control burden created when a technology is deployed faster than the organisation can define ownership, logging, exception handling, and revocation. In AI programmes, governance debt shows up when useful workflows are live but the access model is still improvised.

What's in the full article

GlobalSign's full article covers the statistical breakdown and source-by-source trend details this post intentionally leaves at the summary level:

• The original survey citations behind the market-size, productivity, and security adoption figures.
• The Spanish-language commentary and framing around AI adoption, consumer concern, and workplace impact.
• The full list of 15 statistics, including the Capgemini, Brouton Lab, and Free Agent references.
• The article's closing interpretation of what the 2023 AI trend landscape suggests next.

👉 The full GlobalSign article lists the 15 cited AI statistics and the studies behind them

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and the control patterns that also shape AI-connected workflows. It is designed for practitioners who need to turn identity governance into repeatable operational control.