Should teams centralise AI agent security inside CNAPP or use a dedicated control plane?

Why this is really a runtime enforcement question

Centralising AI agent security inside CNAPP works for asset visibility, posture drift, and attack-path correlation, but it does not answer the narrower question of whether an agent should be allowed to act right now. That decision sits closer to authorization than inventory, because the control has to evaluate the request, the context, and the current risk before the action executes.

CNAPP is strongest when you want to understand the environment around the agent, such as cloud exposure, permissions, and correlated paths into sensitive systems. A dedicated control plane is stronger when the decision must be made at the moment of tool use, API call, delegation, or action approval, especially when the acceptable answer can change per request.

That split matters because “seeing” an agent and “constraining” an agent are not the same control problem. A broad platform can tell you where the agent lives and what it can reach, while a purpose-built plane can decide whether a specific action is permitted under the current policy, identity, and session conditions.

Where CNAPP helps, and where it stops

CNAPP earns its place when agent security is part of a wider cloud risk picture. It can surface overbroad permissions, exposed services, insecure cloud configuration, and risky blast radius, which is useful when the agent is one of many workloads in a shared environment.

That makes CNAPP a good control for discovery and correlation. It can help teams answer questions like which agents exist, what cloud assets they touch, and whether their footprint creates a broader path to compromise. For teams already using cloud-native security telemetry, that context is valuable because agent risk rarely lives in isolation.

Its limit is that environment context does not equal per-action authority. If the security decision is “can this agent invoke this tool, call this API, or modify this record now,” then posture data alone is not enough. The closer the decision gets to active delegation, the more the control needs runtime policy enforcement rather than post hoc visibility.

What a dedicated control plane adds

A dedicated control plane becomes essential when the agent needs task-scoped permissions, just-in-time approval, or per-action checks that can be revoked as conditions change. It gives teams a place to express business rules such as scope, time, purpose, approval state, and boundaries on what a given agent may do.

That is especially important for agents that can chain tools or act across systems. In those cases, the relevant question is not whether the agent exists in a safe environment, but whether each requested action is bounded, attributable, and consistent with current policy. A control plane can also support step-up controls when the requested action crosses a sensitivity threshold.

In practice, this is the layer that can block destructive or high-impact actions even when the agent has access to the surrounding environment. It is also the place to enforce separation between broad observability and narrow authority, so operators can retain cloud-wide insight without giving the monitoring platform the final say over execution.

How to decide the split in a real program

The right design is usually not CNAPP versus control plane, but CNAPP plus control plane with clear division of labour. Use CNAPP for inventory, exposure analysis, and attack-path context. Use the control plane for runtime authorization, delegation, approvals, and action scoping.

A useful decision rule is this: if the control question can be answered from posture alone, CNAPP may be enough; if the question depends on the current request, current user, current agent context, or the exact action being attempted, you need a dedicated enforcement layer. That becomes even more important when agents can operate across multiple SaaS, cloud, and internal systems.

Teams should also be careful not to treat “centralised” as a synonym for “complete.” A single pane of glass is helpful for operations, but it is not automatically the right place to enforce policy. For production agents, architecture should separate detection, context, and decision-making so that visibility does not become a bottleneck for governance.

Risk and Threat Considerations

When agent security is concentrated only in CNAPP, the main risk is false confidence: the team can see the agent’s footprint without actually constraining what it is allowed to do at runtime. That gap becomes material when an agent is compromised, misconfigured, or tricked into taking an unexpected action.

Failure mechanism: Attackers or misbehaving agents exploit the difference between environmental visibility and action-level enforcement, then use existing access to perform unauthorized tool calls, data changes, or lateral movement before posture tools can intervene.

Impact: The likely outcome is excessive agency, broader blast radius, and weaker containment. In the worst case, a monitored agent still becomes a fully capable execution path into sensitive systems because the platform can observe risk but not deny the action in time.

Practitioner Guidance

What to verify: Confirm whether your current stack can answer three separate questions, what agents exist, what they can reach, and what they may do right now. If one product only covers the first two, treat runtime authorization as an additional control requirement, not an optional enhancement.

Decision rule: Use CNAPP as the environment and exposure layer, then add a dedicated control plane wherever agent actions affect production data, privileged workflows, or cross-system side effects. If the agent can materially change state, the decision should not rely on posture data alone.

Common mistake: Teams often centralise dashboards and call that centralised control. The better test is whether you can deny a specific agent action without waiting for a broader security review or cloud alert cycle.

Practitioner takeaway: The safe pattern is layered control, broad context from CNAPP, narrow execution authority from a dedicated plane, and a hard requirement that the runtime decision be separable from the inventory view.

Related resources from NHI Mgmt Group

• How should security teams control AI agent access when external clients can read and act inside Zendesk?
• How should security teams detect AI agent escapes in Kubernetes before they reach the host or control plane?
• How should security teams govern AI agent traffic at the control plane level?
• How should security teams control AI use in browsers without blocking productivity?