OpenAI AgentKit expands AI agent sprawl across enterprise workflows

At a glance

What this is: OpenAI AgentKit turns agent creation into a widely accessible workflow problem, with Noma Security arguing that the core risk is sprawl, hidden appsec exposure, and poorly governed permissions.

Why it matters: For IAM, PAM, and NHI practitioners, the issue is not only who can build agents, but who can approve actions, scope data access, and govern the workflow surface once agents are embedded.

Context

OpenAI AgentKit is a no-code agent builder embedded in a platform that already has broad enterprise reach. The security issue is not the existence of agents alone, but the way distribution turns workflow creation into something many employees can do without passing through normal application security review.

The article frames this as an expansion of agent sprawl across enterprise workflows, with business users able to create and change agents that connect to data sources, tools, and approval paths. That shifts the governance problem from a small number of centrally built automations to a much larger pool of embedded, business-owned workflow logic.

In identity terms, the main concern is not just access to OpenAI itself. It is the downstream permissions, data paths, and action rights that these workflows inherit once they are embedded into business applications and connected to operational systems.

Key questions

Q: What breaks when business users can build agents without security review?

A: The failure is not only unapproved automation. It is the collapse of review, ownership, and boundary control around workflows that can touch production data and operational systems. When business users can publish agents directly, security teams lose consistent visibility into permissions, approval paths, and downstream side effects before the workflow is embedded.

Q: Why do flow agents create more risk than chat agents in enterprise apps?

A: Flow agents usually execute predefined business steps, but they often carry broader permissions and stronger operational authority than chat interfaces. That makes them more dangerous when they can write data, move money, change permissions, or call external services. Deterministic sequencing does not remove blast radius when access scope is wide.

Q: What are the signs that an embedded agent workflow is misconfigured?

A: Look for untrusted input influencing variables, developer messages, approval logic, or file-search content. Other warning signs are unsanitised data leaving the workflow, approval steps missing for destructive actions, and agents able to access systems that the initiating user should not reach. Those are indicators that workflow logic has become an attack surface.

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Technical breakdown

Why distribution changes the agent risk model

No-code agent builders are not new, but distribution changes how quickly they become a security problem. When a capability sits inside a widely used platform, agent creation stops being a specialist activity and becomes something that can spread across departments, applications, and data domains. That creates governance debt because the number of builders grows faster than the number of reviewers. The result is not just more agents. It is more untracked workflows, more inconsistent permission design, and more places where security policy is expressed in low-code configuration rather than controlled code paths.

Practical implication: treat platform-wide agent creation as a governance and inventory problem, not only a development problem.

How flow agents create blast-radius risk

The article draws an important distinction between chat agents and flow agents. Flow agents follow predefined step sequences, which makes them look safer, but they often carry broader permissions because they are meant to execute business processes end to end. That combination is dangerous. A workflow with write access to finance, CRM, or administrative systems can still cause major harm if it is misconfigured, injected, or allowed to execute destructive actions without approval. In other words, determinism in the workflow does not equal safety. Broad tool access plus broad action authority produces a large blast radius even when autonomy is limited.

Practical implication: review flow agents as high-permission applications, not as harmless automation.

Where prompt injection becomes workflow exploitation

AgentKit changes prompt injection from a conversation problem into a workflow problem. If untrusted input is allowed into variables, file search nodes, developer messages, or downstream logic, attackers can influence approval decisions, data retrieval, or transaction handling. That is application-layer exploitation hidden behind an AI interface. The issue is not merely that the model can be tricked. It is that workflow design can turn untrusted content into control input. This is why guardrails need to cover data handling, variable trust, and instruction boundaries, not just model prompts.

Practical implication: examine every point where untrusted input can influence workflow logic, not just the final model response.

Threat narrative

Attacker objective: The attacker aims to exploit weak workflow governance so the agent performs unauthorized actions, exposes sensitive data, or alters business logic at scale.

1. Entry occurs when business users create or modify embedded agents in a platform that many employees already access, expanding the number of potential workflow owners without equivalent security review.
2. Credential and authority abuse follows when the workflow inherits broad access to finance systems, CRM data, policy stores, or external MCP servers, even though the builder may not understand the downstream permissions.
3. Escalation happens when variables, developer messages, or file-search content carry untrusted instructions into approval, authorization, or transaction steps, turning content into control.
4. Impact appears as unauthorized approvals, sensitive data exposure, destructive system actions, or business logic manipulation across embedded enterprise workflows.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• CrewAI Uncrew GitHub token exposure: A CrewAI provisioning error exposed an admin GitHub token for all its private repositories; Noma reported it and CrewAI fixed it in hours.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent sprawl is now a governance problem, not a feature problem: When a platform makes agent building available to large numbers of business users, the control challenge shifts from design-time development to runtime governance. That change overwhelms review models built for a small number of centrally engineered automations. The practical conclusion is that discovery, ownership, and policy enforcement must scale with distribution, not with developer headcount.

Workflow determinism does not reduce blast radius: A flow agent can be more predictable than a chat agent and still be more dangerous because it often carries broader permissions and more direct operational reach. The dangerous combination is fixed sequencing plus production authority across multiple systems. The implication is that practitioners must judge the action set and authority boundary, not the conversational surface.

Hidden appsec surface is the right classification for AgentKit: The article shows that the builder may be low-code, but the deployment surface is application security, data governance, and access control. That means review gates, data sanitization, and permission scoping belong in the security programme, not as optional extras after rollout. Security teams need to treat embedded agent workflows as governed application logic.

Prompt injection becomes instruction-path abuse when variables and developer messages are untrusted: The security failure mode is not only model manipulation. It is letting untrusted content influence the instructions and variables that govern downstream execution. That turns the workflow itself into an attack surface. Practitioners should therefore view trust boundaries in the workflow as first-class control points.

OpenAI AgentKit is accelerating the shadow AI inventory gap: If employees can publish agents where they already work, then security teams lose the ability to assume they know what exists, what it touches, and who can alter it. That assumption has already broken in the NHI world and is repeating in agentic systems. The implication is that inventory and policy enforcement must precede broad enablement.

What this signals

Agent sprawl is an inventory problem before it is an AI problem: Security teams need a reliable view of what has been built, what it can access, and who can change it. Once agent creation moves into business workflows, discovery has to become continuous rather than periodic.

The most important control shift is from model-centric review to workflow-centric governance. Approval gates, variable trust, data sanitisation, and system permissions are the control points that decide whether embedded agents remain bounded or become enterprise-wide risk multipliers.

For practitioners

• Map every embedded agent to an owner and approval path Create a complete inventory of AgentKit workflows, the business owner behind each one, the systems it can touch, and the approval path required before any destructive action.
• Classify flow agents by blast radius, not interface type Separate chat agents from flow agents, then rank each workflow by its write access, external integrations, and ability to process payments, delete data, or change permissions.
• Block untrusted input from control fields Prevent user-supplied content from flowing into developer messages, variables, approval logic, or other fields that influence authorization, routing, or transaction handling.
• Require approval gates for destructive operations Force explicit human approval for any workflow step that can delete records, move funds, modify access, or invoke system commands, even when the sequence is deterministic.
• Sanitise data before any external MCP connection Inspect every payload that leaves the workflow for personal, financial, or strategic data, and stop unsanitised content from reaching external tools or servers.

Key takeaways

• OpenAI AgentKit changes the security problem by making agent creation widely accessible inside enterprise workflows, which expands the inventory and governance burden.
• The greatest risk comes from flow agents that combine broad permissions, cross-system integrations, and weak approval gating, not from chat interfaces alone.
• Security teams should govern embedded agents as production application logic with strict ownership, scoped permissions, and controls on untrusted input and destructive actions.

Key terms

• Flow Agent: A flow agent is an AI agent that follows a predetermined sequence of steps to complete a business process. In practice, it can still be risky because predictable execution does not limit the permissions, data access, or downstream systems the workflow can touch.
• Agent Sprawl: Agent sprawl is the uncontrolled growth of AI agents, scripts, and automation identities across teams and environments. It creates governance strain because each agent can introduce its own permissions, secrets, and ownership gaps, making revocation, review, and accountability harder to sustain.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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 building or maturing an IAM or identity security programme, it is worth exploring.