Notifications
Clear all
Topic starter
14/08/2026 6:34 pm
TL;DR: Enterprises are already running hundreds of AI agents in production, often connected to databases and internal tools, while embedded agents are also appearing inside SaaS products, according to ZioSec’s field notes from Ai4, Black Hat, and DEF CON. The real risk is not autonomous sprawl alone but “chat plus” systems with real credentials, expanding the blast radius beyond what current review and testing processes were built to govern.
NHIMG editorial — based on content published by ZioSec: The Agents Are Already in Production
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read ZioSec’s field notes on AI agents already in production →
AI agents in production are outpacing security controls?
Explore further
14/08/2026 6:41 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI agents in production are outpacing enterprise security controls
