Tech Navigator: A secure operating system for agentic governance

Insights

• Given that agentic AI can plan ahead, chain its actions, and invoke multiple APIs and tools, just controlling the API gateway is insufficient.
• The agent must be supervised once it is inside the organization. This means making sure it only moves where it is allowed, follows predetermined rules, and logs everything it does.
• This requires an operating system (OS) for agentic governance, a central execution environment that also enforces the permissions, rules, and constraints that govern the business in real time.
• The OS market is fragmented into three distinct layers: Hyperscalers, enterprise incumbents, and new age tools, each layer providing its own policy language, runtime mechanism, ontology, and impact on latency.
• However, there is currently no unified OS agent that brings these approaches together, necessitating investment in an operating system layer that can effectively harness the strengths of each.

As AI agents begin to execute tools, plan workflows, and make decisions without human intervention, organizations are having to think about how to manage systems that function within the perimeter of the business and with limited human oversight, and about what can go wrong.

For instance, in July 2025, an agentic AI solution designed to streamline software development through natural language instructions deleted the entire production database of SaaStr.AI, a B2B content platform for software executives. Despite the agent receiving a prompt to “always show proposed changes before implementing the change,” the agent went ahead and deleted the database without explicit approval. Another high-profile incident occurred when Zoho, a provider of business software, leaked sensitive acquisition information in response to an external inquiry. The agent here wasn’t sufficiently constrained, causing harm to the enterprise.

One way to address this is to move beyond controlling the API gateway and instead govern the agent’s runtime environment — where it operates and executes actions.

An operating system for agentic governance

Given that agentic AI can plan ahead, chain its actions, and invoke multiple APIs and tools, just controlling the API gateway is insufficient, since the agent can still bypass intended workflows, access data improperly, and execute actions that could cause reputational harm. Allowing access via APIs does not protect the internal environment from agents not behaving as expected once they have access: the agent must be supervised once it is inside the organization. This means making sure it only moves where it is allowed, follows predetermined rules, and logs everything it does. This is critical for governance of nondeterministic workflows.

This requires an OS for agentic governance. The OS acts as a central execution environment for the agent, executing the agent’s logic, and enforcing permissions, rules, and constraints that govern the business in real time. Ad-hoc security tools, onboarded on a case-by-case basis, like Galileo for monitoring the quality of data and model outputs, IBM for data lineage, and AWS Cedar for permissions are insufficient if deployed without the OS intelligence layer to coordinate security guardrails and curtail the systemic-level risk particular to agentic AI.

This OS coordinates everything that the agent does or is allowed to do, organizes and integrates all types of inputs to the system, and applies a structured set of rules and domain knowledge, or ontology, in real time, ensuring failsafe agentic operations.

Gateway and sidecars — why both are essential

Security and system governance fail in the agentic era for several reasons. First, traditional API gateways treat AI traffic like web traffic, inspecting data payloads at a central checkpoint. While this is a necessary element in perimeter security and governance, agentic policy enforcement needs more than just gateway governance. Mesh architectures, a way of organizing software and systems so that different components can connect and communicate directly with each other without centralized orchestration, once optional and relegated to special use cases in legacy microservices landscapes, are gaining prominence. This requires rules, monitoring, and coordination across all connections to ensure reliability, security, and consistency.

Gateways can perform broad-based enterprise policy governance such as removing sensitive personal data, enforcing profanity filters, and request transformation, where the system sanitizes inputs for security and policy compliance. However, gateways struggle to distinguish between a legitimate audit query and a malicious data exfiltration attempt without further knowledge of the agent’s internal state. Such policies need to be enforced closer to the agent.

In the OS, governance logic should be distributed between centralized, top-down tools and processes like Galileo to the agent’s software container, also known as a sidecar. This is a solution where before the agent can execute any command, the sidecar validates the action against a local policy engine. This sidecar intercepts instructions and sits next to the agent. It checks both syntax and the business ontology, or what entities exist and how they relate, to understand if, for instance, the customer is in a valid internal state to receive an email or promotion.

For the Salesforce Einstein AI suite of products, the runtime sidecar is used in model and metadata management to feed the AI inference engine with contextualized and trusted business data, while also grounding AI responses in trusted customer relationship management (CRM) metadata. Outside of enterprise software-as-a-service products such as Salesforce, general enterprise products such as Kong Mesh and Solace Agent Mesh provide similar capabilities to enforce policies locally at the agent level. These products either rely on open standard policy enforcement plugins or can be customized to provide these localized capabilities.

Elements of the OS brain

To build this OS, organizations need a standard language to express constraints that the intelligence layer works under — working across applications, infrastructure, ontology, and cost.

Applications: AWS Cedar, a policy language for defining and enforcing access control for both humans and agents, is emerging as the preferred standard for application-level agentic permissions due to its focus on readability and formal verification. The standard enables fine-grained authorization capabilities — verifying whether agent A can perform action B on resource C, for instance — and supports a schema-based approach, meaning it can reason about hierarchies, which is perfect for agentic AI as it maps directly to agent roles. For instance, it can work out whether “managers” includes “senior managers” or if “IT support” includes “AI administrators.” Alternatives to AWS Cedar are available, such as the Open Policy Agent from the cloud native computing foundation (CNCF), which is supported by several enterprise gateway and mesh product vendors.

Infrastructure: Defining policy as code can also be created at the infrastructure level. The CNCF standard for infrastructure leverages complex logic language that checks which rules, policies, or governance should be enforced automatically, along with whether infrastructure changes meet standards. In this way, runtime is proactively validated and governed. However, because of the complexity of the language, it is difficult for business stakeholders to read and also lacks the specialized authorization reasoning engine particular to AWS Cedar.

Ontology: Just as important as the chosen OS standard, agents need a business physics, or enterprise rules, engine that defines what things are, where data lives, and what constraints the agent is working under. Package providers like Salesforce and SAP provide a ready-made business ontology: an agent already on Salesforce, for instance, would already have a view of the relationships between the account, the contact opportunity, and the quote. The challenge here, then, would be bridging the gap between what an external agent understands, and the policies already set up in the system. For functions that do not rely on package providers like Salesforce, enterprises need to build their own frameworks and semantic ontology for specific domains. For example, in financial services, a custom ontology would need to be built using the semantic data layer from Chapter 1 of this report.

Cost: Finally, implementation of the OS should also consider the cost of running the agent. The agent should run within its allotted or available token limits, set out in the FinOps budget — requiring another level of governance that should be set out  in the policy. This will ensure that if recursive calls are made over and again — where a software function calls itself repeatedly as part of solving a problem — there’s a circuit breaker to pull the request once the token limit has been exceeded.

Onboard the right partner

The OS market is fragmented into three distinct layers:

• Hyperscalers: These, like AWS (Cedar) provide infrastructure as policy and allow developers to define rigid access policies for agents, though close proximity to the partner is needed for deeper quality metrics.
• Enterprise incumbents: IBM Watson is an example of the second layer, established OS players that work at the process level, where tracking tool usage and performance drift is critical, along with blocking inputs and outputs based on profanity and hate speech.
• New age tools: Finally, popular tools like Galileo have been developed more recently for enhanced reliability and security, often using specialized language models like Luna to score agent responses and ensure they are both safe and accurate. Lakera is another tool that is often used for enhanced security, with the ability to inspect input prompts for malicious intent.

Figure 1 compares each OS stack in terms of focus, policy language, runtime mechanism, ontology, and impact on latency.

Figure 1. Selecting the right OS stack depends on OS approach

Source: Infosys

A strategic approach to building your OS

However, at present there is no single OS agent that pulls all these approaches together. To bring them together, an agentic orchestration controller can perform a unified system call check so that when an agent tries to call a tool, the controller simultaneously checks AWS Cedar for permissions, the ontology to ensure the business state is valid, Lakera for safe inputs and Galileo for sound reasoning. By doing this, governance is executed at all layers of the OS stack, and if all checks pass, the organization can be confident that the agent is safe to execute instructions.

To get ahead, three implementation phases are required:

Phase 1 – Create the foundation:
This means standardizing all agent permissions on a standard framework like AWS Cedar; deploying new age guardrails by implementing technology like Lakera and Galileo for security and hallucination management; and building the descriptive ontology or knowledge graph that defines critical business entities and their valid states.

Phase 2 – Create the participative mesh:
The participative mesh is the network of agents and tools that allows for agency, shared context, and collaborative governance within the OS. At this stage, the governance sidecar, which intercepts all agent tool calls, should be developed. Also important is to ensure the sidecar is integrated into the stack; the sidecar should call the Cedar engine and check the ontology registry before allowing any tool execution. Enterprise products such as Kong Mesh and Solace Agent Mesh enable the deployment of this infrastructure out of the box, along with the additional policy enforcement infrastructure. Finally, make sure protocols are standardized by adopting the model context protocol (MCP) or FIPA ACL 2.0, enabling agents to request permissions in a standardized manner from the sidecar.

Phase 3 – Realize the OS:
At this final stage, the onus is moving to self-governing agents that can query the sidecar proactively, rather than just being blocked reactively. For example, the agent can query the sidecar with the question “I plan to do X, is this allowed?” Once this is in place, make sure to feed all decisions and logs from the sidecar into the governance control plane for long-term audit retention and regulatory reporting. Here, organizations should use the plugin architecture to ensure all logs are automatically recorded in the governance control plane.

The security imperative

According to our report, Responsible enterprise AI in the agentic era, almost all executives (95%) have experienced at least one type of problematic incident from their use of enterprise AI, and almost three-quarters (72%) of executives who experienced damage from an enterprise AI deployment rated it at least “moderately severe.” According to the same data, executives find reputational damage much more threatening to their business than financial losses.

Without adequate governance for agentic AI systems, companies risk reputational damage from access and security lapses. The time is now to invest in your own OS brain, governing agents so they know what to do and how to do it.