OpenAI AgentKit expands AI agent sprawl across enterprise workflows

At a glance

What this is: OpenAI AgentKit commoditises agent creation inside a mainstream AI platform and widens the agent sprawl problem for enterprise workflows.

Why it matters: IAM, IGA, PAM, and security teams now have to govern AI agents built by non-technical users, where access, data flow, and approval logic can be altered outside traditional software controls.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Noma Security's analysis of OpenAI AgentKit risk and agent sprawl

Context

OpenAI AgentKit matters because it shifts agent creation from specialised tooling into a platform many enterprises already deploy and trust. For identity teams, that changes the control problem: workflows with data access, approval logic, and external connections can now be created by business users who are outside normal software governance.

The core issue is not that agents exist. It is that no-code agent building expands the number of identities, permissions, and data paths that need governance, while making those changes faster than traditional review cycles can keep up. That creates a direct challenge for NHI governance, agentic AI oversight, and the access controls surrounding human-built automations.

The article’s premise is typical of the current market: capability is spreading faster than policy, inventory, and enforcement. That is exactly the kind of gap identity programmes have seen before with service accounts, API keys, and shadow IT, except the blast radius now includes embedded AI workflows.

Key questions

Q: How should security teams govern business-built AI agents in low-code platforms?

A: Start with discovery, ownership, and access boundaries. Business-built agents should not reach regulated data or operational systems until they are inventoried, assigned to an accountable owner, and checked against policy. The key control is not just approval at creation, but a repeatable review of what the agent can access and do after it is deployed.

Q: What breaks when AI agent workflows can be edited outside AppSec review?

A: What breaks is the assumption that production behaviour only changes through controlled software release processes. When business users can edit prompts, variables, or approval logic directly, access policy becomes configuration drift, not code drift. That creates blind spots for inventory, change management, and segregation of duties, especially when the workflow touches sensitive data or operational systems.

Q: Why do AI agents increase the risk of oversharing sensitive data?

A: AI agents often aggregate context from multiple sources, then present or transmit that information in ways a user would not normally see. If the agent’s access is broader than the user’s, or if data is sent to external tools without sanitisation, oversharing becomes a governance failure. The fix is to align workflow permissions, data minimisation, and user entitlements before deployment.

Q: How can identity teams reduce shadow AI risk without blocking innovation?

A: Use narrow, policy-backed access paths that allow approved AI use while making unsanctioned use visible. Shadow AI grows when controls are too blunt and users work around them. The better approach is precise classification, monitored exceptions, and clear remediation when data use drifts out of policy.

Technical breakdown

No-code agent builders turn workflow logic into governable identity surface

AgentKit sits in the class of embedded agent-building platforms where business logic is expressed through prompts, tool calls, branching rules, and external integrations rather than source code alone. That matters because the security boundary moves from a developer-reviewed application to a configuration surface that can be altered by non-technical users. In practice, the agent becomes a new control plane for access to data and actions, while still depending on downstream application and MCP permissions. Once that happens, the real security question is not whether the model can reason, but whether the surrounding workflow can be constrained, inspected, and approved like any other production identity path.

Practical implication: Treat agent definitions, tool connections, and approval steps as production changes that require governance before release.

Prompt injection becomes workflow exploitation when variables and developer messages are misused

Traditional prompt injection targets the model’s instruction-following behaviour. In AgentKit-style workflows, the attack surface is broader because user input can be reused in variables, file search, and developer messages that shape later steps. If untrusted input can influence authentication, authorisation, or payment logic, the attacker is no longer just steering an answer, they are manipulating business process execution. That is why this class of issue belongs in application-layer security, not only AI content moderation. The problem is especially acute when workflow builders do not understand how data from receipts, tickets, or knowledge bases can carry attacker-controlled instructions into privileged steps.

Practical implication: Validate every untrusted input before it can influence downstream decisions, prompts, or approval states.

MCP connections extend the blast radius of agent workflows

Model Context Protocol is the interface that lets agents reach tools and data sources, which means every connector changes the agent’s effective privilege boundary. When agent workflows stream internal data to external MCP servers, or when they query knowledge bases with broader access than the end user should have, the result is oversharing by design rather than by accident. The security concern is not simply leakage. It is that an agent can aggregate context from multiple systems and then disclose or act on it in a way no individual user session would be allowed to do. That makes MCP governance a core part of identity control for agentic systems.

Practical implication: Catalogue every MCP endpoint, then enforce data minimisation and least-privilege access per workflow.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI workflow into a vehicle for unauthorised data access, business logic manipulation, or destructive action execution.

1. Entry occurs through legitimate platform access, where a business user creates or edits an agent workflow inside a widely distributed AI environment.
2. Escalation follows when untrusted input, variables, or developer messages alter approval logic, data flow, or tool usage inside the workflow.
3. Impact occurs when the agent discloses sensitive data, executes destructive actions, or multiplies shadow AI workflows across the enterprise.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Agent sprawl is now an identity governance problem, not just an AI adoption problem. When agent building moves into a platform already embedded across the enterprise, the number of actors with access to create workflows expands far beyond security’s line of sight. That changes the governance model from centrally designed automation to distributed identity creation with downstream permissions. The practitioner conclusion is straightforward: agent inventories, ownership, and approval boundaries must be treated as first-class identity controls.

Workflow configuration is becoming a new form of privilege assignment. Expense logic, customer support flows, and data access rules no longer live only in code reviewed by AppSec. They can be altered by business users through no-code interfaces that still reach production systems, which means policy drift can happen without a traditional deployment event. The implication is that identity programmes need to govern configuration as access, because the workflow itself now defines what the agent can do.

Oversharing through agents is a least-privilege failure, not a model failure. The risk is not that the AI knows too much in the abstract. The risk is that the workflow can gather context from multiple systems and present or transmit it outside the bounds of the original user’s permissions. That is a classic NHI governance issue wearing an AI interface. Practitioners should recognise that data-path control, not just model safety, determines the real blast radius.

Agentic AI requires a named concept we can actually govern: the workflow blast radius. This is the total impact an agent can create through its connected tools, data sources, and approval paths. AgentKit-like systems expand that blast radius faster than conventional review cycles can map it, which means security teams must rethink how they classify, approve, and continuously monitor agent-driven access. The practical conclusion is to govern the path, not only the prompt.

Static approval expectations break down when business users can publish agents directly. Traditional controls assume the people closest to the business process are not also shaping production access. That assumption no longer holds when non-technical users can define workflows that reach operational systems with little security training. The implication is that access governance and application governance are converging, and identity teams need to own that convergence rather than wait for AppSec to absorb it.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Our research also found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a deeper breach lens, the 52 NHI Breaches Analysis shows how identity exposure and weak lifecycle control turn access into incident persistence.

What this signals

Workflow blast radius: enterprises should expect AI agent governance to converge with application governance, because the workflow now defines the privileges, data paths, and approval gates that matter. As adoption spreads, the challenge is less about whether agents exist and more about whether security can inventory and recertify them before business users normalize unsupervised production changes.

The next control gap will be between what teams can discover and what they can actually enforce. With AI access expanding across everyday collaboration and business platforms, security leaders need to decide whether agent definitions, tool bindings, and approval logic belong in change management, access governance, or both. In practice, they belong in both, which is why the operating model has to change before the deployment curve steepens further.

The pressure on IAM and PAM teams is to treat AI workflows as governed access paths rather than detached automations. That means mapping where agent permissions exceed user entitlements, where external tool calls widen the data perimeter, and where approval gates are missing. If those signals are not in the identity programme, they will show up later in incident response.

For practitioners

• Inventory every agent workflow before production release Discover workflows built with Agents SDK, ChatKit SDK, or other agent builders, then record owner, purpose, connected tools, and data sources in a single inventory.
• Require approval gates for destructive agent actions Block any workflow that can delete data, modify permissions, process payments, or trigger system commands unless a human approval step is enforced before execution.
• Classify MCP connectors as privilege-bearing integrations Treat each MCP server connection as a governed access path and review whether the agent’s effective permissions exceed the end user’s entitlements.
• Sanitise untrusted input before it reaches workflow logic Remove attacker-controlled text from variables, file search outputs, and developer messages before those values can influence authorisation or transaction decisions.
• Extend access reviews to agent configuration changes Add agent definitions, prompt updates, and tool bindings to recertification so changes in workflow behaviour are reviewed as identity changes, not only code changes.

Key takeaways

• OpenAI AgentKit lowers the barrier to creating AI agents, which expands agent sprawl and pushes governance into identity territory.
• The main risk is not model intelligence alone, but workflow misconfiguration that can expose data or enable destructive actions.
• Identity teams should inventory, classify, approve, and recertify agent workflows as production access paths, not side projects.

Key terms

• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Approval Workflow Blast Radius: Approval workflow blast radius is the amount of damage a single approved request can cause once it passes through an identity or business process. It is shaped by role design, segregation of duties, and the systems reachable from the approval path.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Noma Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Workflow examples showing how no-code agent builders handle prompts, tools, variables, and approval gates in practice.
• Specific misconfiguration patterns involving prompt injection, unsanitised variables, and destructive actions without human approval.
• Examples of how MCP connections expand data access and where agent workflows can overshare sensitive information.
• Noma Security's own detection and policy enforcement approach for embedded agents across the development lifecycle.

👉 The full Noma Security post covers workflow examples, misconfiguration patterns, and policy controls in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.