AI agents in production are outpacing enterprise security controls

At a glance

What this is: This field note argues that enterprise AI has moved into production faster than security practice, with “chat plus” deployments and embedded SaaS agents creating new access and data exposure paths.

Why it matters: It matters because IAM, PAM, and broader governance teams now need to treat AI agents as systems with real credentials, tool reach, and reviewable risk, not as harmless interfaces.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read ZioSec’s field notes on AI agents already in production

Context

Enterprise AI risk is increasingly an access-control problem, not just a model-governance problem. When hundreds of agents are connected to databases, internal tools, and customer data, the security question becomes who or what can act, with what privileges, and under which controls. In this article’s framing, the primary identity security issue is that AI systems are being given real reach before governance has caught up.

The article’s main claim is that the market has shifted from prototypes to production faster than security programmes have adapted. That makes agent identities, delegated credentials, and embedded tool access part of the operational attack surface. For teams already working on NHI governance, the overlap is obvious: if the system can call tools, it needs an identity model, lifecycle controls, and reviewable boundaries.

This is also a broader third-party risk issue because vendors are embedding agents directly into SaaS products. A product that now reasons over data and tools is not the same system it was last year, even if the procurement record still treats it that way.

Key questions

Q: How should security teams govern AI-assisted work that inherits human credentials?

A: Treat it as a delegated identity path, not a simple user session. Security teams should map the human, service account, and agent involved, then monitor the sequence of actions, the tools used, and the systems reached. That lets teams detect when authorised activity drifts into a higher-risk behavioural pattern before containment becomes impossible.

Q: Why do embedded AI agents increase enterprise risk so quickly?

A: Embedded agents widen the trust boundary because they add natural-language input, delegated tool access, and a reasoning layer inside software that was previously static. That means the same product can now leak data, trigger actions, or misuse permissions in ways traditional application reviews often miss. The risk rises fastest when the agent inherits broad access without separate governance.

Q: What breaks when AI testing is only done annually?

A: Annual testing assumes the system stays materially unchanged between reviews, but agent behaviour can shift after model updates, prompt edits, and new tool connections. That creates blind spots in both security and compliance evidence. The result is stale assurance: controls may look valid on paper while the live system has already changed.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

Why “chat plus” creates a higher-value identity target

“Chat plus” is the article’s most useful shorthand for enterprise AI that looks conversational on the surface but holds real credentials behind the interface. The model may not be autonomous in the strict sense, but it can still access databases, internal tools, and customer records through delegated permissions. That makes the access path more important than the interface. In IAM terms, the risk is not only authentication but delegated authority that is difficult to reason about once a prompt can influence action selection.

Practical implication: treat the AI layer as a privileged access path and inventory its credentials, scopes, and tool grants like any other high-risk identity.

Embedded SaaS agents change the trust boundary of the product

When a vendor adds an agent to a SaaS product, the product’s security model changes even if the procurement label does not. Natural-language input becomes a new attack surface, while tool access and reasoning expand the ways an attacker can influence data flows. This is where identity and application security intersect: an embedded agent can inherit existing permissions, but it also introduces a new decision layer that may act on manipulated instructions or leak sensitive data through unexpected tool use.

Practical implication: reassess vendor risk as if the software had been re-architected, because the agent layer changes both the trust boundary and the control assumptions.

Continuous testing matters more than point-in-time review

The article is right to dismiss annual testing as too static for AI systems whose behaviour shifts with model updates, prompt changes, and new tools. A point-in-time control assumes the system remains stable between reviews. Agents do not. Their effective privilege can expand or shrink with configuration drift, context, and connected resources. For governance teams, that means testing must become part of runtime assurance rather than a periodic compliance exercise. This is especially relevant where AI systems touch secrets, customer data, or operational systems.

Practical implication: move from annual assurance to continuous red teaming and configuration review for any agent that can reach sensitive data or production tools.

Threat narrative

Attacker objective: The attacker wants to convert a conversational interface into a privileged execution path that exposes sensitive data or triggers unauthorised actions.

1. Entry occurs through an AI agent or embedded assistant that is connected to internal tools, databases, or vendor-controlled workflows and exposed to prompt-driven manipulation.
2. Escalation happens when the model is allowed to act with delegated credentials, so a malicious instruction can turn conversational input into tool use or sensitive data access.
3. Impact is data leakage, unauthorized actions, or broader trust collapse when the agent’s real reach exceeds the governance model around it.

NHI Mgmt Group analysis

AI agents are becoming non-human identities before most enterprises have agreed that they are identities. The article’s strongest point is that an agent with real credentials, tool access, and data reach is already an identity governance problem, whether the programme labels it that way or not. IAM and PAM teams need to stop treating the conversational layer as benign metadata and start treating it as an access-bearing system. The practitioner conclusion is simple: if it can act on systems, it needs lifecycle controls.

“Chat plus” is the named concept that best describes the current enterprise risk pattern. It captures the gap between a human in the loop and a model with production reach. This is not full autonomy, but it is still dangerous because the model can be induced to use tools against real data under real credentials. From an NHI perspective, the control problem is delegated privilege without a governance model that matches the system’s reach. The practitioner conclusion is to classify these agents by access scope, not by marketing language.

Embedded agents complicate third-party risk because the vendor product itself has changed identity posture. A SaaS product with an embedded agent is no longer just static software plus authentication. It is a dynamic system with a reasoning layer that can touch data and tools, which means vendor questionnaires built for conventional application security will miss the real failure modes. The practitioner conclusion is to retune TPRM for agentic behaviour, not just for data handling.

Continuous assurance is now the baseline for any AI system with operational reach. The article correctly notes that model updates, prompt changes, and new tool connections alter behaviour continuously. That creates governance debt if teams continue to rely on annual reviews, because the risk surface moves faster than the review cycle. The practitioner conclusion is to make runtime testing, access review, and drift detection part of the operating model.

Agent governance will converge on identity, telemetry, and containment rather than model novelty. The market is already showing that the winning question is not whether an agent can reason, but whether it can be constrained, audited, and revoked like any other production identity. For identity leaders, that means aligning NHI policy with AI operations and grounding controls in lifecycle, least privilege, and evidence. The practitioner conclusion is to build governance around revocability and scope, not around the promise of the model.

What this signals

The programme signal is clear: agents are moving from experimentation to live operational access, which means identity teams need to treat AI reach as part of the access inventory rather than as a separate innovation track. The organisations that will cope best are the ones that can answer who issued the credential, what it can touch, and how quickly it can be revoked when behaviour changes.

Chat plus governance gap: enterprises are adopting conversational systems with real credentials faster than they are building controls for delegated action, telemetry, and containment. That gap will show up first in secrets management, then in vendor risk, then in audit evidence when reviewers ask why a model had access it could not be bounded to. Teams should align AI rollouts with the same evidence discipline they apply to privileged identities.

If your programme already tracks service accounts and API keys, extend that discipline to agent-connected tools and embedded SaaS assistants. The operational difference is that the access path now includes a reasoning layer, so drift can happen without a code deploy. Continuous review, not static attestation, becomes the meaningful control.

For practitioners

• Inventory every agent as a privileged identity Record which agents can reach databases, internal tools, customer data, or vendor APIs, then map the exact credentials and scopes each one holds.
• Reassess SaaS vendor risk for embedded agents Update third-party assessments to ask how the product handles natural-language input, delegated tool use, and agent-driven data access.
• Shift to continuous agent testing Run red-team style testing whenever prompts, models, or tool connections change, because behaviour can drift after deployment.
• Apply least privilege to model-connected tools Reduce access to the minimum set of systems and actions required for each agent, and separate read, write, and administrative paths wherever possible.
• Build revocation and monitoring into the operating model Ensure agent credentials, integrations, and approvals can be revoked quickly, and watch for unusual tool invocation or data access patterns.

Key takeaways

• Enterprise AI is no longer a pilot problem because agents are already holding real credentials and reaching production systems.
• The evidence points to a governance gap: static review cycles cannot keep pace with model changes, new tools, and embedded agent behaviour.
• Identity teams should govern agents as revocable, scoped non-human identities and build continuous assurance into the operating model.

Key terms

• Chat Plus: A conversational AI deployment that looks like a chat interface but also has real access to tools, data, or operational systems. The risk is not the chat UI itself, but the delegated permissions and hidden reach behind it.
• Embedded Agent: An AI agent built into a third-party product or SaaS service rather than operated entirely by the customer. It changes the product’s trust boundary because the agent can influence data flow, action selection, and tool use inside software that may already hold sensitive access.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.
• Continuous Agent Testing: An assurance pattern that tests AI agents repeatedly as prompts, models, and connected tools change. It replaces one-time validation with ongoing scrutiny because the agent’s effective behaviour can shift after deployment without a formal code release.

What's in the full article

ZioSec's full analysis covers the operational detail this post intentionally leaves for the source:

• Field notes from Ai4, Black Hat, and DEF CON on how enterprises are actually deploying AI agents in production
• Examples of the most common enterprise agent patterns, including Copilot-style deployments connected to databases and internal tools
• Discussion of how embedded agents alter third-party risk assessments and why static questionnaires miss the change in system behaviour
• Why continuous pentesting and compliance planning matter for teams that are already running agents at scale

👉 ZioSec’s full post covers the enterprise deployment patterns, vendor risk implications, and testing gaps in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps practitioners turn identity controls into operating discipline across human and non-human estates.