Zenity GA Inline Prevention for Copilot Studio and Foundry Preview

Zenity’s announcement that it is delivering inline prevention for Microsoft Foundry and has reached general availability (GA) for inline controls in Microsoft Copilot Studio marks a notable moment in the rapid professionalization of agent security — but it also raises immediate operational questions for enterprise security teams planning to scale agentic AI across production systems.

Background​

Microsoft’s agent platforms — most visibly Microsoft Foundry and Microsoft Copilot Studio — are designed to let organizations build, orchestrate, and run agentic AI that connects models, data, tooling, and workflows. Over the last 12–18 months Microsoft has added agent runtimes, Model Context Protocol (MCP) support, hosted agent services, and tighter identity and governance hooks to make agent deployment more tractable for enterprises. Those capabilities make agentic AI more useful, but also increase the potential for high-impact mistakes and abuses when agents interact with privileged systems, sensitive data, or external services.
Zenity positions itself as a purpose-built, end-to-end security and governance platform for AI agents. The company’s product messaging centers on three interlocking ideas: agent discovery and posture management, runtime visibility and detection, and inline prevention and response that can block unsafe actions inside the agent execution path. The recent press materials state Zenity’s inline prevention is now generally available for Copilot Studio agents, with preview capabilities for Foundry arriving as Foundry continues to expand.
This article summarizes what Zenity announced, verifies the core technical claims against publicly available Microsoft and industry reporting, and offers a practical analysis of strengths, limitations, and the operational steps security teams should take when integrating inline prevention into an agentic stack.

---

What Zenity announced (summary)​

• Zenity announced inline prevention for Microsoft Foundry (preview coming soon) and confirmed that inline prevention for Microsoft Copilot Studio is generally available.
• The company frames the capability as runtime, deterministic enforcement — “hard boundaries” that prevent unsafe agent behavior before it completes, rather than simply detecting or logging suspicious activity after the fact.
• Zenity’s platform claims to deliver:
• Real-time enforcement that intercepts and blocks unsafe tool invocations and data exfiltration.
• Comprehensive analysis of agent data flows and tool calls across the agent lifecycle.
• Protection against indirect prompt injection and other agent-specific attack patterns.
• Integration into Microsoft’s agent development ecosystem to allow policy enforcement tied to agent identity and execution context.
• Microsoft product leaders are quoted as endorsing the approach, and Microsoft product updates show Foundry and Copilot Studio are expanding runtime and governance features that make such integrations technically feasible.

These headline claims are consistent with Zenity’s product pages and with Microsoft’s public documentation describing Foundry’s agent services, MCP support, hosted agent runtimes, and identity/integration work that surfaces agents in Entra and other governance systems.

---

Overview: Why inline prevention matters for agentic AI​

The new threat surface​

Agentic AI changes the threat model in three important ways:

• Agents act autonomously and can chain actions across systems (APIs, databases, email, CRM), which raises the risk of unintended privileged actions.
• Agents frequently handle or synthesize sensitive data, increasing the risk of data exposure and exfiltration.
• Common defensive patterns for models (rate limiting, monitoring prompts, static guardrails) are insufficient when a multi-step agent can adapt at runtime and call arbitrary tools.

Inline prevention seeks to close a gap that detection-only solutions leave open: it enforces policy in the execution path so that an unauthorized call never completes, even if the agent’s internal reasoning or prompt fiddling tries to bypass buildtime controls.

Buildtime vs. runtime controls​

• Buildtime controls (policy gates, hardened prompts, role limits) are important but limited because agents evolve: new connectors, model updates, and on-the-fly reasoning can introduce risk after deployment.
• Runtime enforcement provides a last line of defense that stops unsafe actions when they attempt to execute, giving security teams deterministic control over what an agent can and cannot do.

Zenity’s message — anchored on hard boundaries and deterministic runtime controls — maps to this runtime enforcement model.

---

Technical verification: what’s being claimed and what public sources show​

The core technical claims in Zenity’s announcement break down into three verifiable pieces:

• Copilot Studio inline prevention is GA
• Zenity’s company announcements and product pages indicate Copilot Studio integration reached general availability earlier in 2025, delivering inline controls for agents built in that environment. Microsoft’s Copilot Studio documentation and partner statements corroborate that Copilot Studio supports buildtime governance and that third-party runtime controls are being integrated. Multiple sources independently confirm that Zenity and Microsoft have been publicly discussing this integration at industry events and on product blogs.
• Foundry integration (inline prevention) is in preview
• Microsoft’s Foundry roadmap and recent dev blogs show the platform is adding hosted agent services, MCP support, and richer identity and governance hooks, which are required primitives for embedding runtime enforcement. Zenity’s announcement explicitly frames the Foundry support as “coming soon in preview,” which aligns with public Microsoft messaging that Foundry features are being rolled out in preview phases.
• Runtime “hard boundaries” and prevention of prompt injection/data exfiltration
• Technical descriptions match a model where policy enforcement is embedded in the agent’s execution path — intercepting tool calls, validating intent, and blocking requests before side-effects occur. Microsoft’s Foundry and Copilot Studio docs describe how agents invoke tools and how control/observability hooks can be inserted in the runtime, which makes inline prevention feasible. Independent coverage and vendor documentation illustrate similar defensive approaches from other security vendors, indicating the technique is widely discussed and technically plausible.

Caveat: some marketing claims — for example, statements that a vendor is “trusted by Fortune 500” or performance/scale metrics — are typical in vendor press but require verification on a customer-by-customer basis. Where exact numbers or customer names are asserted, those claims should be validated directly with the vendor or through customer reference checks.

---

What “hard boundaries” and “deterministic runtime controls” mean in practice​

Hard boundaries​

• A hard boundary enforces an immutable policy at the runtime layer: if an agent tries to call a disallowed API, access forbidden data, or exfiltrate a field, the runtime immediately blocks the action and returns a constrained response to the agent.
• This differs from soft enforcement (alerts, throttles, or retries) by providing a guaranteed stop condition — the action does not proceed.

Deterministic runtime controls​

• Deterministic controls use explicit, machine-enforceable rules and context (agent identity, tool invoked, user intent signals) to decide whether an action should be permitted.
• Determinism matters for compliance and for predictable incident response: security teams must be able to reproduce why an agent was blocked and when.

Examples of what runtime enforcement can do​

• Prevent an agent from sending unredacted PII to an external email or webhook.
• Block an agent from invoking a privileged internal API unless the request matches a signed business context.
• Stop indirect prompt injection by ensuring tool parameters cannot be contaminated by model-generated content unless validated.

---

Strengths of Zenity’s approach​

• Runtime uniqueness: Embedding enforcement in the execution path removes ambiguity about whether a check occurred and eliminates a window where an agent’s action could succeed before being retroactively reversed.
• Agent-centric policy: Policies tied to agent identity and lifecycle are more manageable at scale than per-connector or per-application controls that ignore agent orchestration.
• Comprehensive lifecycle coverage: Combining discovery, posture management, runtime detection, and prevention creates a defense-in-depth model that addresses both misconfiguration and active attacks.
• Alignment with Microsoft platform evolution: As Foundry and Copilot Studio expose richer observability and identity hooks (agent identity in Entra, MCP tool registries, hosted runtimes), inline prevention becomes both possible and operationally clean to integrate.
• Practical attack mitigation: Inline enforcement can neutralize common agent-specific attacks (indirect prompt injection, covert data exfiltration) that are hard to prevent purely via buildtime controls.

---

Potential risks, limitations, and open questions​

No security control is a silver bullet. The following are realistic operational risks and limitations security teams should weigh before relying heavily on inline prevention:

• False positives and business disruption
  Deterministic blocking can prevent legitimate actions if policies are too strict or incomplete. For business-critical agents, a hard stop might interrupt processes and cause downtime. Designing exception flows and safe fails is essential.
• Performance and latency overhead
  Inline checks add processing steps to the execution path. For high-throughput or low-latency agents, enforcement must be optimized and benchmarked. Performance impacts could lead teams to relax safeguards unless they are assured of minimal overhead.
• Coverage gaps
  Agents can use multiple runtimes and connectors. Inline enforcement is most effective when it is embedded at the platform/runtime layer; agents that run outside managed Foundry/Copilot environments (e.g., custom agent runtimes, local prototypes, third-party agent frameworks) may evade enforcement unless integrated consistently.
• Policy complexity and lifecycle drift
  Policies must reflect business needs, compliance obligations, and acceptable risk. Maintaining correctness as agents proliferate is non-trivial and requires governance processes, testing, and automated policy validation.
• Supply chain and trust
  Inline enforcement depends on the integrity of the enforcement path itself. If an attacker compromises the runtime, enforcement can be bypassed. Ensuring enforcement primitives are tamper-resistant is crucial.
• Vendor coupling and portability
  Deep integration with a vendor platform (e.g., Microsoft Foundry) may lock organizations into a particular control model. Security architects should evaluate portability, exportability of policies, and cross-platform enforcement options.
• Auditability and forensics
  Blocking an action is valuable only if logs, context, and forensic artifacts are sufficient for incident response and compliance reporting. Enforcement must generate clear, auditable records.
• Legal and compliance nuance
  Policies that automatically redact or drop data flows may have regulatory implications (e.g., data subject access, records retention). Legal teams must be involved in policy design.

Where Zenity or Microsoft make broad claims about scale or effectiveness, those statements should be validated with real-world tests and proofs-of-concept in an organization’s own environment.

---

Operational checklist: how to prepare for and deploy runtime inline prevention​

• Inventory existing and planned agents
• Map agents by purpose, data access needs, and owners. Include prototypes and departmental copilots.
• Define clear policy taxonomy
• Classify data sensitivity, allowed tool invocations, and permitted external integrations. Capture exceptions and escalation rules.
• Integrate identity and least privilege
• Ensure agents have unique identities (Entra identities, service principals) and strictly scoped permissions.
• Establish staging and canary deployments
• Test enforcement in a staged environment; run enforcement in “observe” mode before full blocking.
• Define fail-safe behavior
• For business-critical actions, design fallback workflows and human-in-the-loop approvals.
• Benchmark performance impact
• Measure latency and throughput before and after enforcement. Plan capacity and scaling accordingly.
• Connect logs to SIEM and incident response
• Ensure blocked events, context, and request payloads (appropriately redacted) are sent to monitoring and IR systems.
• Automate policy testing in CI/CD
• Validate changes to agents and policies with automated tests that emulate attack patterns and common workflows.
• Plan for cross-platform coverage
• For agents that operate off-platform, consider network-level controls, sidecar enforcement, or universal enforcement proxies.
• Engage legal and compliance early
• Align policies with regulatory obligations (retention, audit trails, privacy) and ensure required artifacts are preserved.

---

Integration considerations with Microsoft Foundry and Copilot Studio​

• Identity and agent registry: Microsoft’s work to surface agents in identity and policy systems (e.g., Entra) is a foundational enabler of per-agent policy enforcement. Security teams should ensure agent identities are provisioned with the minimal necessary rights and that policy attribution is automated.
• MCP and tool registries: Model Context Protocol (MCP) makes it easier to standardize how agents call backends and tools. Inline prevention that enforces allowed tool lists and validates caller context will be most effective when it can reference MCP tool manifests as part of policy decisioning.
• Hosted agent service vs. local runtimes: Hosted runtimes reduce the chance of bypass, because enforcement can be applied at the managed service level. Local or self-hosted agents require alternative enforcement techniques (e.g., sidecars, network proxies).
• Observability and telemetry: Microsoft’s Foundry observability updates are complementary — they provide the tracing and metrics needed to triage blocked actions and understand agent behavior over time.
• Policy portability: Evaluate whether policies created for Copilot Studio/Foundry can be exported or applied to other agent runtimes to reduce vendor coupling.

---

Practical scenarios: how inline prevention would act​

• Scenario 1 — Data exfiltration attempt
  An agent constructs a report containing customer PII and attempts to send it to an external webhook. Inline prevention recognizes the destination and the data classification and blocks the outbound call, logging the attempt and returning a sanitized response to the agent.
• Scenario 2 — Indirect prompt injection via tool output
  A browsing tool fetches a web page that contains crafted content attempting to override the agent’s instruction. Deterministic checks validate tool outputs and scrub or isolate untrusted content before it can alter subsequent actions.
• Scenario 3 — Privilege escalation via chained calls
  An agent tries to escalate privileges by calling an internal admin API after obtaining a token via a misconfigured connector. Enforcement validates both agent identity and the requested operation against policy and halts the chain.

These scenarios illustrate why runtime enforcement is valuable: it stops the action right before the side-effect, preserving system integrity.

---

Recommendations for security leaders​

• Treat runtime enforcement as complementary to, not a replacement for, robust buildtime controls and secure development practices.
• Start with a limited, high-value pilot: pick a set of agents that touch sensitive data or critical systems and test enforcement in observe mode first.
• Develop an operations playbook for blocked actions: who triages, how to approve exceptions, and how to remediate agent misconfigurations.
• Invest in policy authoring and testing tooling. Policy complexity grows quickly; automated validation reduces risk of outages from misapplied rules.
• Demand forensic transparency from vendors: blocked events must include context, explainability, and tamper-evident logs for compliance.
• Evaluate vendor interoperability: prefer enforcement that can be extended across runtimes to avoid blind spots as multi-cloud and hybrid agents proliferate.
• Include privacy and legal teams in policy design to ensure redaction and retention behaviors meet regulatory requirements.

---

Where to be cautious: claims that need further validation​

• Customer and scale claims (e.g., “trusted by Fortune 500” or broad adoption figures) should be validated through direct references or customer testimonials when procurement teams evaluate vendors.
• Performance overhead and latency impact should be benchmarked in each organization’s environment; vendor numbers are a starting point but not a guarantee.
• The efficacy of preventing advanced attacks (e.g., sophisticated supply-chain manipulations) depends on where enforcement is placed and how agents are instrumented; assume some attack vectors will require additional controls beyond runtime blocking.

---

The broader security landscape and vendor differentiation​

Inline prevention is becoming a competitive differentiator among security vendors targeting agentic AI. Several companies are converging on the same pattern — combining observability, policy-as-code, and runtime enforcement — but the devil is in the integration details:

• Is enforcement enforced centrally at a managed runtime, as a sidecar, or via a network proxy?
• Are policies declarative, auditable, and testable within existing DevOps workflows?
• Can policies be shared across clouds and runtimes, or are they locked to a single platform?
• Does the vendor provide robust incident response tooling for agents, including rollback, quarantine, and automated remediation?

Security buyers should evaluate these dimensions when comparing vendors.

---

Conclusion​

Zenity’s inline prevention for Microsoft Copilot Studio (now generally available) and its forthcoming preview support for Microsoft Foundry represent a pragmatic, forward-looking approach to securing agentic AI. Embedding hard boundaries and deterministic runtime controls into the agent execution path closes an important gap between buildtime governance and post-hoc detection.
The approach brings clear advantages: stronger guarantees, tighter policy linkage to agent identity, and the ability to stop dangerous actions before they occur. But it is not without trade-offs: policy complexity, potential false positives, performance considerations, and coverage gaps across heterogeneous runtimes are real operational concerns.
For enterprises serious about scaling agentic AI, the right path is a staged, measured adoption: inventory agents, pilot runtime enforcement where risk is highest, benchmark impacts, and harden DevOps and governance processes to keep policies accurate as agents evolve. When combined with least-privilege identity, robust observability, and legal/compliance oversight, inline prevention tools such as the ones announced by Zenity can provide a determinative layer of protection — shifting several classes of high-risk agent failures from “might happen” to “will be stopped and audited.”

---

Source: Business Wire https://www.businesswire.com/news/h...for-Capabilities-in-Microsoft-Copilot-Studio/