Microsoft has open-sourced a runtime toolkit that places policy enforcement between an AI agent and the corporate systems it wants to use.
The approach addresses a limitation of static security. Agents generate tool calls dynamically, so pre-deployment scanning cannot predict every command created from a future prompt. A compromised or hallucinating model can attempt to overwrite data, order products or expose customer records.
Runtime control judges the action at the moment it is requested.
Policy intercepts the tool call
When an agent queries inventory, writes code or accesses cloud storage, it leaves the model and calls an external function. Microsoft’s framework intercepts that request before it reaches the target.
A central policy engine compares the proposed action with the agent’s authority. An inventory reader that tries to issue a purchase order is blocked and the event is logged for human review.
This produces an auditable record of autonomous decisions. Developers do not need to encode security in every prompt; policy is separated from application logic and managed as infrastructure.
The layer also protects legacy systems that were never designed to receive non-deterministic requests. Even if the model is manipulated, the underlying database or ERP remains behind an independent enforcement point.
Open source supports mixed model estates
Enterprises build agents from open libraries, internal code and models supplied by competing vendors. A Microsoft-only control tied to one cloud would be easy for developers to bypass.
Open sourcing allows the toolkit to sit around local models, Anthropic services or hybrid architectures. Security vendors can add dashboards and incident-response integrations while the community reviews the common baseline.
The strategy reduces lock-in and may help create a shared runtime standard. It also increases the chance that governance becomes part of development workflows instead of a proprietary add-on introduced late.
Open code does not guarantee secure configuration. Organisations still need policy ownership, testing and disciplined updates as agents gain new tools.
Runtime governance controls cost as well as risk
Agents can consume resources in loops, repeatedly calling paid APIs or proprietary databases. A badly configured research task can create a large cloud bill before anyone notices.
The toolkit can enforce limits on tokens, API frequency and action counts within a period. These boundaries make costs more predictable and stop runaway processes from exhausting systems.
Quantitative controls also support compliance. Teams can show not only what an agent attempted, but which rule allowed or denied it.
A mature programme requires cooperation among developers, security, operations and legal teams. Developers understand tool behaviour, security defines threats, finance sets resource limits and legal interprets obligations.
Model providers will continue improving built-in safety, but infrastructure operators cannot delegate final responsibility to them. The system executing a model’s decision needs its own authority to say no.
Microsoft’s toolkit represents a broader shift from trusting output filters to governing actions. The critical boundary is no longer only what the model says. It is what the enterprise allows that model to do.
As agent capability grows, runtime policy becomes the final checkpoint between probabilistic reasoning and deterministic consequence. Organisations that build that checkpoint now will be better prepared for workflows whose future commands cannot be known in advance.
Policies should be versioned and tested like code. A rule that blocks legitimate work encourages developers to seek bypasses, while one written too broadly leaves dangerous actions available. Teams can replay recorded tool calls against proposed changes and verify that expected requests pass while known violations fail. Emergency defaults also matter: if the policy service is unavailable, a high-risk agent should stop rather than continue without control. Runtime security is dependable only when its own failure modes are understood and the enforcement layer cannot quietly become a single point of unsafe permission.
