The data and action layer is where an AI agent actually touches information, systems, and infrastructure. Security controls placed here are harder to bypass because they govern real permissions, execution rights, and observable events rather than relying on the model to comply voluntarily.
Expanded Definition
The data and action layer is the operational boundary where an AI agent reads data, calls tools, changes records, and executes tasks in connected systems. In agentic AI security, this is the layer that matters most because it governs what the agent can actually do, not just what it appears to understand. Controls at this layer typically include authorization checks, scoped tool permissions, logging, transaction approval, and environment safeguards that limit blast radius if the agent behaves unexpectedly.
NHI Management Group treats this layer as distinct from the model layer and the prompt layer. A model may generate a recommendation, but only the data and action layer determines whether that recommendation becomes a ticket update, a database write, an API call, or a privileged workflow execution. That distinction is central to NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises access control, auditing, and system integrity as enforceable protections around real-world actions.
Usage in the industry is still evolving, and some vendors blur this layer with orchestration, tool integration, or general runtime security. The most common misapplication is treating prompt filtering as sufficient, which occurs when organisations assume unsafe actions are prevented even though the agent still has direct write access to systems.
Examples and Use Cases
Implementing the data and action layer rigorously often introduces workflow friction, requiring organisations to weigh automation speed against tighter approval and logging requirements.
- An AI agent drafts and submits a helpdesk change, but the final ticket transition requires a policy check and human approval before execution.
- A procurement agent queries an ERP system for supplier data, yet its API key is restricted to read-only access unless a separate workflow authorises updates.
- A customer support agent can create case notes, but it cannot close accounts or alter payment settings without step-up verification and audit logging.
- A security operations agent enriches alerts from a SIEM and SOAR platform, while write-back actions are constrained to specific queues and approved response playbooks.
- An NHI governance workflow monitors service accounts and secret usage so that agent-issued actions are tied to accountable identities and recorded for review.
These patterns align with control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls because the decisive question is not whether the AI can recommend an action, but whether it can perform one safely. For agentic systems, OWASP Agentic AI Top 10 is also useful for understanding where excessive tool authority and unsafe action boundaries create exposure.
Why It Matters for Security Teams
Security teams need to understand the data and action layer because it is where AI risk becomes operational risk. If access is too broad, an agent can expose sensitive data, corrupt records, trigger unsafe transactions, or amplify a minor prompt injection into a material business incident. If access is too narrow, the organisation loses the efficiency gains that justified agent deployment in the first place. The practical challenge is designing controls that are specific to the action being taken rather than assuming a single policy can govern all tools and systems.
This layer also connects directly to identity governance. Agent actions should be attributed to a known identity, constrained by least privilege, and monitored like any other privileged workflow, especially when non-human identities are used to broker access. Guidance from OWASP Non-Human Identity Top 10 helps security teams think about service credentials, token scope, and lifecycle control for agent-run operations.
Organisations typically encounter the consequences only after an agent changes production data, sends an unauthorised request, or overwrites a record set, at which point the data and action layer becomes operationally unavoidable to address.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance stresses unsafe tool use and excessive action authority. | |
| OWASP Non-Human Identity Top 10 | NHI guidance covers service credentials and non-human access used by agents. | |
| NIST CSF 2.0 | PR.AC-4 | Access control and least privilege underpin safe agent actions at this layer. |
| NIST AI RMF | AI RMF addresses governance of AI system actions, accountability, and risk. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege and auditing controls are directly relevant to this layer. |
Constrain tool access, require approvals for risky actions, and log every agent execution.
Related resources from NHI Mgmt Group
- Who is accountable when authorization logic is split between the application and the data layer?
- Who is accountable when application-layer ERP data is stolen?
- Who should be accountable when Claude takes an action that affects regulated data?
- How do teams know if their identity data layer is working?
