Intro
Enterprise AI no longer lives behind a single API.
Employees use conversational assistants. Developers run coding agents with access to repositories and terminals. Business teams connect AI to internal documents, SaaS applications, and databases. Custom agents use MCP servers and tools to take actions across enterprise systems.
Each surface may offer its own activity logs, permissions, and administrative controls. Anthropic’s Enterprise plan, for example, provides audit logs and role-based permissions for Claude usage. These controls improve visibility, but they do not answer the most important security question:
Was this AI interaction—and every action that followed—consistent with the user’s original intent and the organization’s policy?
Enterprises need more than a central place to collect events. They need an intent-aware policy plane that can test agent behaviour before deployment, evaluate decisions while an agent is running, and intervene before an unsafe action causes damage.
Problem
Enterprise AI security is fragmented
A typical enterprise may have:
- AI chat applications used by employees
- Coding agents operating on developer machines
- Customer-facing AI applications
- Internally built agents and multi-agent workflows
- MCP servers connected to databases and business tools
- AI gateways monitoring prompts and responses
- SaaS agents operating inside third-party platforms
Security controls are often implemented separately for every surface. One system records chat activity. Another monitors API traffic. IAM controls user permissions. Application logs capture tool executions.
This creates visibility, but not necessarily understanding.
An agent can start with a legitimate request, retrieve manipulated content, change its plan, call an approved tool, and perform an action that the user never intended. Every individual event may appear valid when inspected alone.
The risk exists in the trajectory.
Logs explain what happened after the action
Audit trails are valuable for investigation and compliance. But an event recorded after execution cannot prevent:
- A secret from being inserted into a prompt
- An agent from retrieving restricted information
- A prompt injection from changing the agent’s task
- An MCP tool from being used outside its intended scope
- A high-impact action from proceeding without approval
- Sensitive information from leaving through a model response
For agentic systems, the security decision must sometimes happen between the agent’s decision and the resulting action.
Tool permissions do not capture intent
Traditional access control asks:
Is this identity allowed to use this tool?
Agentic security must also ask:
Is this tool call necessary for the task the user authorized?
An employee may legitimately have access to a CRM export tool. That does not mean an agent acting on their behalf should export the entire customer database while preparing a summary.
OWASP recommends least-privilege tool access, independent authorization for sensitive actions, human approval for high-impact operations, and structured adversarial testing. These controls matter because prompt injection and excessive agency can cause an agent to misuse permissions it technically possesses.
Solutions
1. Map the complete agentic decision boundary
Start with the entire workflow, not only the model endpoint.
For every agent, document:
- Who or what can initiate it
- What task it is intended to perform
- Which models and prompts influence its decisions
- What data sources it can retrieve from
- Which tools, skills, and MCP servers it can invoke
- What permissions and credentials those tools possess
- Which actions are reversible or high impact
- Where approval or policy enforcement can occur
This creates a practical view of the agent’s blast radius.
2. Express policies around intent, context, and action
An agent policy should contain more than an allowlist of tools.
A useful policy decision may consider:
| Dimension | Policy question |
|---|---|
| Identity | Who initiated the workflow? |
| Intent | What outcome did the user authorize? |
| Context | Did the agent consume untrusted external content? |
| Data | What classification of information is involved? |
| Tool | Is this tool necessary for the requested task? |
| Action | Is the action read-only, reversible, or destructive? |
| Environment | Is the agent operating in development or production? |
| Approval | Does this action require human confirmation? |
This allows the same tool call to receive different decisions depending on why, where, and by whom it is being invoked.
3. Test policies before deployment
Runtime controls should not be deployed on assumptions alone.
Security teams should red-team complete agent workflows using adversarial prompts as repeatable test cases. Testing should include:
- Direct and indirect prompt injection
- Sensitive-data extraction
- Tool misuse and parameter manipulation
- Permission escalation
- Multi-step policy bypass
- Malicious or misleading tool output
- Retrieval of poisoned documents
- Attempts to trigger irreversible actions
- Actions that drift from the user’s original request
The output should include the evidence, severity, affected decision boundary, and recommended control—not merely a pass or fail.
4. Enforce decisions at runtime
Runtime enforcement should sit close enough to the action to intervene.
Depending on the risk and available control point, the policy plane should be able to:
- Allow the action
- Allow it with additional monitoring
- Redact or mask sensitive information
- Restrict parameters or reduce scope
- Require human approval
- Substitute a safer tool or workflow
- Block the action
- Alert the appropriate owner
Deterministic rules work well for explicit constraints such as blocked credentials, prohibited tools, and restricted data types. Contextual evaluation is needed when the decision depends on the relationship between user intent, session history, retrieved content, and the proposed action.
A secure system needs both.
5. Turn production evidence into better tests and policies
Agent behaviour changes as prompts, tools, models, data sources, and integrations change.
The policy plane therefore needs a continuous feedback loop:
- Test the workflow.
- Capture the evidence.
- Convert findings into policies.
- Enforce those policies at runtime.
- Monitor decisions and attempted violations.
- Add newly observed behaviour to the test suite.
- Retest before the next release.
This turns security from a one-time review into an adaptive control process.
dwaar’s POV
At dwaar, we believe the policy plane for enterprise AI must connect two security stages that are often treated separately.
The first is pre-deployment adversarial testing.
dForge tests complete agentic workflows using adversarial prompts as test cases. The objective is to identify where an agent can be manipulated into leaking data, misusing a tool, bypassing policy, or moving beyond its intended decision boundary. Findings are captured with evidence and severity so teams can understand the behaviour that produced the risk.
The second is intent-aware runtime enforcement.
dFence evaluates live agent behaviour against organization-wide and agent-specific policy boundaries. Deterministic controls can enforce explicit restrictions, while contextual judges assess whether an action remains consistent with the identity, task, session, and user intent behind it.
The important step is connecting the two.
A red-team finding should not end as a report. It should become a runtime policy, a release test, or an approval requirement. Likewise, a new runtime violation should become an adversarial test that the agent must pass before the next deployment.
That creates the security lifecycle agentic applications need:
Test → capture evidence → define policy → enforce → monitor → retest
A unified enterprise AI policy plane is valuable, but centralization alone is not the destination. The real objective is to ensure that every agent stays within the intent and authority it was given—even when its inputs, context, tools, and decisions change.