Should organisations treat agentic data control planes as part of IAM or data governance?

Both. The control plane governs who or what can request data, how context is attached, and which outputs are acted on, so it sits at the intersection of access control and data handling. Teams that split these responsibilities usually miss the policy boundary that decides what an agent can safely do.

Why This Matters for Security Teams

Agentic data control planes collapse a familiar organisational split: the same control point now decides access, context, and action. That means the issue is not just who can read data, but what an agent can infer, carry forward, and trigger from that data. If teams place this only in IAM, they usually miss data handling rules; if they place it only in data governance, they usually miss runtime privilege and authorisation. The practical failure is policy drift between two teams using different control vocabularies.

For agentic systems, the control plane sits close to trust decisions because it mediates tool access, retrieval context, and downstream execution. That makes identity, authorisation, and data classification inseparable at the decision point. OWASP’s guidance for agentic applications treats tool misuse, privilege abuse, and context poisoning as first-order risks, which is why a control plane cannot be managed as a passive data catalogue. The organisational question is really whether the policy boundary is enforceable at runtime, not which team owns a diagram.

In practice, many security teams discover the gap only after an agent has already combined permissive access with sensitive context and acted on it.

How It Works in Practice

In a working design, the control plane does three jobs at once: it authenticates the requesting entity, evaluates whether the request is allowed for the requested data and task, and records enough context for audit and response. That is why it naturally spans IAM and data governance. IAM supplies identity, policy enforcement, entitlement decisions, and revocation. Data governance supplies classification, usage constraints, retention logic, and rules about secondary use. The control plane is the place where those decisions must converge.

Operationally, the most useful mental model is to treat each agent action as a policy decision with both access and data dimensions. A request to fetch a record, enrich it with context, and pass it to a tool is not a single permission check. It is a chain of checks:

Can this agent or workflow identity request the data at all?
Can it request this class of data for this purpose?
Can the retrieved context be combined with other sources?
Can the resulting output be acted on automatically or must it wait for review?

That sequence is why organisations need both entitlement controls and data-use controls. Data governance alone often stops at classification labels, while IAM alone often stops at whether a token is valid. An agentic control plane has to answer both “who is calling?” and “what may this data be used for next?” The strongest implementations use least privilege, purpose-based policy, short-lived access, detailed logging, and explicit step-up approval for actions that change state or move sensitive data.

For teams looking for a broader governance model, NIST’s AI Risk Management Framework is useful for framing accountability, measurement, and oversight, while NIST CSF 2.0 helps connect those controls to governance, protection, detection, response, and recovery. NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0 both support the idea that the control plane should be measurable, reviewable, and bounded by policy rather than left to application teams alone.

These controls tend to break down when the control plane can retrieve data from one system but enforce actions in another without a shared policy model.

Common Variations and Edge Cases

Tighter control often increases coordination overhead, requiring organisations to balance speed of agent execution against the cost of more explicit policy decisions. That trade-off becomes sharper when agents act across multiple datasets or business functions, because a single policy owner rarely understands every downstream effect.

One common variation is a platform team that runs the control plane while data owners define the policy. That can work, but only if the enforcement layer is consistent and the policy language is precise enough for runtime decisions. Another edge case is read-only agents: teams sometimes assume they belong mainly in data governance because they do not write anything. In reality, read-only agents can still create material risk if they aggregate, infer, or expose sensitive context in a new form. A third edge case is human-in-the-loop review. Review helps, but it does not remove the need for IAM-style controls because reviewers should be approving bounded actions, not compensating for unlimited access.

Current guidance suggests treating the control plane as a shared policy boundary with explicit ownership on both sides. The practical test is whether a control decision changes both access and data handling at the moment the agent acts. If it does, the boundary should be managed jointly rather than assigned to a single function.

Risk and Threat Considerations

The main risk is over-permissioned agent behaviour, where a valid identity is allowed to retrieve more data than it should, combine it more broadly than intended, or act on it without sufficient guardrails. That creates exposure even when no single component looks misconfigured in isolation.

Failure mechanism: Attackers and misuse scenarios both exploit the same pattern, excessive trust at the control plane. If an agent can obtain sensitive context, reuse it across tools, and trigger downstream actions, then a stolen token, a poisoned prompt, or a bad policy decision can turn a routine workflow into data exfiltration or unauthorised action.

Impact: The result can be loss of confidentiality, uncontrolled data propagation, incorrect automated actions, and weak accountability for who approved the decision chain. At scale, these failures are hard to detect because logs often show legitimate access events rather than an obvious intrusion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A1 — Agentic Access Control	Agentic control planes govern agent permissions and tool use.
Recommendation — Enforce least-privilege, step-up approval, and tool-scoped access for agent actions.
NIST AI RMF	GOV — Govern	This is an AI governance boundary that needs accountable policy ownership.
Recommendation — Define accountability, policy ownership, and oversight for agentic data decisions.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The control plane depends on authenticating the caller and authorising action.
	GV.RM — Risk Management Strategy	Shared control-plane ownership needs a formal risk and governance strategy.
Recommendation — Bind agent requests to strong identity, entitlement checks, and revocation. Document the shared IAM and data-governance risk model for agentic controls.
NIST SP 800-63	IAL/AAL — Identity Assurance and Authentication Assurance	Agentic requests rely on assurance that the calling identity is trusted.
	FAL — Federation Assurance Level	Federated agent access often depends on trustworthy delegated assertions.
Recommendation — Set assurance levels for machine or delegated identities before permitting action. Validate federated assertions before allowing agents to consume governed data.

Practitioner Guidance

What to prioritise: Define the control plane as a joint policy boundary first, then assign operational ownership. If access approval and data-use approval live in separate systems, establish which system is authoritative for runtime decisions and which one is advisory.

What to verify: Check that the agent cannot move from data retrieval to action without an explicit policy decision, and verify that sensitive outputs are logged with enough context to reconstruct both the identity decision and the data-handling decision.

Decision rule: If the control changes who can act, what data can be combined, or whether output can be executed automatically, treat it as both an IAM control and a data governance control. If it only labels data without enforcement, it is incomplete for agentic use.

Practitioner takeaway: The safest operating model is not to choose one owner, but to make the runtime policy boundary enforce both identity and data rules at the same decision point.