Safely manage your Zendesk from the AI assistant you already use, via the Deltastring MCP. Beacon configuration platform
← Back to news
ai

Varonis Agent IBAC keeps AI agents within their intended boundaries

Varonis has launched Agent Intent-Based Access Control (IBAC) within Atlas, a runtime enforcement layer designed to prevent AI agents from deviating from their intended scope and accessing data they shouldn't. The capability addresses a genuine operational risk: agents operating within enterprise systems have demonstrated a tendency to go rogue, exposing sensitive data or executing unintended actions like deleting production databases. Agent IBAC works by comparing an agent's actual behaviour—the tools it invokes, the data it accesses, the parameters it passes—against the original user instruction and the agent's reasoning process. When misalignment is detected, the system can alert, block, modify, or escalate to human review in real time. Critically, Atlas sits inline between the agent and the underlying model, meaning enforcement happens before actions execute rather than after logs are reviewed.

The implications for CX teams deploying agentic systems are substantial. Most customer service platforms—Zendesk, Salesforce Service Cloud, and others—are moving toward autonomous agents that handle ticket routing, data retrieval, and customer account access. These agents require broad permissions to be useful, which creates the exact conditions Agent IBAC addresses: high-access identities making decisions without human oversight. The question becomes whether your current governance framework can distinguish between an agent legitimately pulling customer records to resolve a ticket and the same agent attempting to exfiltrate data or access accounts outside its scope. Role-based access control alone cannot make this distinction at runtime. Agent IBAC's tunable sensitivity settings—lenient, balanced, and strict—allow teams to calibrate enforcement based on data sensitivity, meaning you could run strict policies on regulated customer data whilst allowing agents more latitude in lower-risk interactions.

The full-session evaluation capability carries particular weight for support teams managing multi-turn interactions. Agents can be compromised gradually through cumulative drift or multi-turn jailbreak attempts, where no single action triggers concern but the sequence does. For teams already running Agentforce or similar autonomous systems, this suggests your current monitoring approach may be blind to attacks that unfold across multiple customer interactions. The quarantine feature—blocking an agent identity for a defined window—provides a circuit breaker that prevents repeated exploitation. However, the real operational question is whether your security and CX teams have the shared governance model needed to act on these detections without creating friction. A strict policy that blocks agent actions too frequently will frustrate customers; a lenient one defeats the purpose. Success depends on how well your organisation can tune intent-based rules to your specific risk tolerance and customer experience requirements.