When the enterprise revoke a model, configure the interface and API key, and as long as it could access the model, gather usage statistics, and check logs when something went wrong, it was essentially up and running.

But as Agents, MCP tools, and Skills begin entering the enterprise, the AI invocation chain is rapidly lengthening.

A single user request may first reach an Agent, which calls a model to make a judgment, then invokes an MCP tool to read data, modify a ticket, or execute an operation; the process may also load multiple Skills and continue calling other Agents.

At this point, what the enterprise faces is no longer merely a "model interface."

It is evolving into an AI capability chain that genuinely participates in business operations.

And the nature of the problem is changing accordingly.

Who provides the model, which tools an Agent can call, who is authorized to execute, whether sensitive data can leave the environment, why an anomalous call was blocked, how many tokens were ultimately consumed, and which project the cost should be attributed to—if these matters remain scattered across different clients, Agents, tools, and model platforms, the enterprise will quickly lose a unified view.

So, once AI moves beyond single-model invocation toward Agent-based execution, what the enterprise needs to solve is no longer just "how to connect the model," but rather:

How to bring the AI capabilities entering the enterprise under unified access and unified control, and make every invocation visible and traceable.

This is the problem we set out to solve.

ZStack Zentrix is an enterprise-grade AI gateway positioned as a unified access and governance plane for models, MCP tools, Agents, and Skills.

Setting between AI capability providers and consumers, ZStack Zentrix brings previously fragmented capabilities into a single managed entry point and centrally handles publishing, authorization, routing, security control, auditing, and cost accounting. Zentrix does not train models, nor does it replace the Agent orchestration of business systems; what it addresses is how AI capabilities enter the enterprise, who may use them, how they are governed at call time, and how they are traced after use.

What Enterprises Need to Manage: Four Distinct Types of AI Capabilities

The first type is the model.

When different teams each connect directly to AI model vendors and maintain their own API keys, it becomes difficult for the enterprise to centrally manage credentials, quotas, and costs. This is especially true for large models metered by token: a successful call does not, by itself, tell you how many resources it consumed.

For example, in an internal test, an Agent mounted with a full toolset consumed roughly 14.1k tokens in its very first round of requests—before the user had even posed a real question—simply because it carried the tool definitions. Yet in a traditional access log, only a single record might remain. The request succeeded, but the token consumption and cost attribution were never clearly accounted for.

The second type is MCP tools.

MCP tools connect AI to enterprise data and business systems—they can read knowledge bases, but also write to databases, send emails, or modify tickets.

If these tools are primarily configured by engineers within local clients, the enterprise will struggle to gain a unified view of tool sources, credentials, invocation scope, and operation logs. Compared with errors in model output, a tool with write and execute capabilities, once out of control, directly impacts real business systems.

The third type is the Agent.

As Agents begin collaborating via mechanisms such as A2A (Agent-to-Agent), the enterprise must manage not only individual Agents but also the discovery, identity, invocation permissions, and accountability chains between Agents.

When one Agent calls another, the other party’s address, capabilities, version, and permissions may all change. If teams continue to maintain these relationships manually, it will be hard to sustain continuous operation and unified governance.

The fourth type is the Skill.

As a reusable capability, Skills are continuously mounted onto different Agents, which also introduces issues around versioning, provenance, dependencies, and installation scope.

The same Skill may exist in multiple copies and versions. Once a risk is identified, the enterprise needs to know where it is installed, whether it can be disabled uniformly, and how subsequent versions are redistributed.

Models, MCP, Agents, and Skills play different roles and create different management challenges, but once they enter the enterprise, they all converge on the same set of requirements:

Who may acquire them, who may invoke them, how they are controlled during the process, what usage happened, and whether they can be traced after something goes wrong.

This is why Zentrix brings all four capability types into a single distribution and governance plane:

It does not change how they are originally used, but establishes on the enterprise side a unified mechanism that is visible, distributable, controllable, and auditable.

One Entry, One Management Platform

The real problem is not that enterprises lack tools to manage these AI capabilities, but that different capabilities often each come with their own management approach.

Models have their own gateways, API keys, and quota systems; MCP Servers are configured separately by different clients; Agents have their identities and invocation relationships maintained by individual business teams; and Skills are installed and upgraded alongside specific Agents or runtime environments.

The more capabilities there are, the more easily permissions, credentials, limits, policies, and audits get fragmented across different systems.

If the enterprise rebuilds a management system from scratch for every new type of AI capability, then the richer its AI capabilities become, the more fragmented its governance will be.

Zentrix’s core judgment is:

Capability forms may differ, but the managment language should be unified.

Within the platform, models, MCP, Agents, and Skills are all abstracted as enterprise capabilities that can be distributed, authorized, and audited. Policies can target an entire capability class, or drill down further to a specific model, MCP Server, individual tool, Agent, caller, session, or deployment environment.

The value of this "multi-axis" expression is not merely that the platform supports more object types, but that different AI capabilities reuse the same organizational, identity, permission, policy, and audit framework. When the enterprise adds new capabilities, it can reduce the redundant build-out of new governance systems.

It should be noted that unified governance has one precondition: the relevant invocations must pass through the managed entry point. If a client bypasses the gateway and connects directly to the upstream, that invocation will naturally not enter the gateway’s policies, ledger, or audit. Therefore, in implementation, the gateway must centrally hold the upstream credentials, while the business side uses only gateway access credentials that are revocable, expirable, and auditable.

From Acquisition to Traceability: Covering Three Governance Phases

Putting different AI capabilities into a single management entry point only solves the problem of "unified management " Once operations actually begin, the enterprise must also embed its management requirements into the complete lifecycle of a single capability usage.

An AI capability generally goes through three phases from entering the enterprise, to being acquired by a user or system, to being actually invoked, and finally to producing a runtime record:

Before usage: resolving "who may acquire it, who may use it";

During usage: resolving "whether this invocation may pass, and how it should be executed";

After usage: resolving "what happened, why it happened, and who bears the cost."

Around these three phases, Zentrix links permissions, credentials, runtime policies, security, auditing, and cost into a single management chain.

The three phases are not isolated feature sets but a continuous chain: a capability is first registered and authorized, then each invocation passes through policy evaluation, and finally settles into queryable, verifiable records.

Before Usage: Managing Capabilities, People, and Credentials

Multi-layer Permissions: Bringing the Four Capability Types into One Organizational Relationship

In Zentrix, the role hierarchy, workspaces, and functional groups can serve as permission subjects, while models, MCP, Skills, and Agents are uniformly distributed as enterprise capabilities. A single functional group can simultaneously be granted a certain model, a certain MCP service, a certain Skill, and a certain Agent, eliminating the need to maintain multiple separate lists.

The platform also provides SSO, account, and session security configurations. Enterprises can map groups in their IdP to functional groups, so that personnel changes stay synchronized with the existing organizational system, reducing the need to redundantly maintain membership relationships within the AI platform.

As a result, "which AI capabilities a given person may use" can be queried within a unified relationship; and permission changes take effect along the same organizational structure.

Publishing, Exposure, and Approval: Entering the Catalog Does Not Mean Usable

When a capability is registered on the platform, it only means it has entered the scope of management—it does not mean all users can call it directly. Publishing and exposure are used to distinguish a capability’s management state from its usable scope: the platform first confirms whether a capability may enter the enterprise catalog, then decides to which organizations, workspaces, or functional groups it should be exposed.

For high-risk capabilities, human approval can also be added. For example, a user-uploaded Skill may contain unsafe logic or inappropriate dependencies. The platform performs a unified security scan of the Skill and shelves it only after administrator review, reducing the risk of unverified capabilities entering the production environment directly.

Centralized Credential Hosting: The Business Side No Longer Stores Upstream Keys

Each access party exists on the platform as an independent consumer, with its own credentials, quotas, and accounting basis. Credentials can be given an expiration period, and can also be reset or disabled. When an employee leaves, a project ends, or a key is suspected of being leaked, the administrator can centrally remediate on the platform side, without having to inspect business-system configurations one by one.

The real authentication information for model vendors and external systems is retained on the gateway side and is invisible to the user-side Agent; what the client receives is a controlled access credential. This not only reduces the spread of upstream keys but also provides the basis for metering by user, project, and system.

During Usage: Making Every Invocation Pass Through Explicit Judgment

Routing and Distribution: Business Conditions and Compliance Jointly Drive Decisions

Routing rules can combine conditions such as request path, model, request headers, URL parameters, data classification, personal-information type, data source, caller, traffic labels, time window, canary cookie, and client CIDR.

This means routing does not judge solely on "which model is being called," but can also fold business and compliance requirements into the same decision chain. For example: general Q&A may call an external model; but if a request is marked confidential, hits a specific personal-information category, or originates from a financial system, it is instead routed to an internal inference service or directly rejected.

Configuring compliance conditions and routing actions together reduces the inconsistencies caused by maintaining security policies and traffic policies separately.

When a rule is hit, the platform can route to a designated model or reject the request. Traffic splitting supports weighted request hashing and weighted round-robin: the former keeps the same logical request stably hitting the same target, while the latter smoothly distributes consecutive requests across multiple targets—useful for model canary releases, traffic weighting, and service allocation across business lines.

For instance, in the early rollout of a new model, the enterprise can first direct a small portion of traffic to the new model while the rest continues on the existing service; it can also bind different requests to different model tiers based on business line, data level, or caller. Here, routing is not merely load balancing—it also reconciles the trade-offs among cost, quality, and compliance requirements.

Rules can also return a reason code, making it easier for the caller to understand the outcome and locate it in the logs. For abnormal cases such as rewrite failures, a secure default of rejecting the request can be applied.

Traffic Limiting, Concurrency, and Circuit Breaking: Preventing One Anomalous Call from Affecting the Entire Chain

An Agent’s invocation pattern differs from traditional human requests. A single task may call multiple models and tools in succession, and may also produce looped calls or sudden bursts of concurrency due to anomalous logic.

Therefore, Zentrix isolates along two directions: the caller and the upstream service.

For callers, request frequency, concurrency, and cumulative invocation volume can be set per consumer, preventing a single Agent, project, or business system from consuming excessive resources; for upstream models and services, a circuit-breaking mechanism identifies sustained anomalies and fails related requests fast when a dependency fails, preventing the problem from propagating further down the call chain.

The platform also provides concurrency limits, rate limits, total invocation caps, invalid-attempt protection, and exemptions, and supports soft and hard upper bounds based on runtime resources.

These mechanisms address more than just "limiting the number of calls"; they let the enterprise isolate resource and fault-impact scope when multiple Agents, business systems, and models share the same AI infrastructure.

Security Guardrails: Covering Input, Output, and Various Evasion Techniques

When AI was only responsible for generating text, errors often stayed at the output layer; but once an Agent can access knowledge bases, read business data, or even call tools to perform operations, sensitive information and risky content in both input and output can further impact real business systems.

Zentrix therefore provides unified security guardrails within the gateway invocation chain, detecting and handling user input and model output separately.

The platform covers common risk types such as PII, secrets and credentials, content risk, and enterprise term libraries. For sensitive information such as names, ID numbers, bank cards, access tokens, and API keys, it can audit, mask, or block according to different rules, or adjust subsequent routing based on data sensitivity level.

For different enterprises and industries, security rules need not be built entirely from scratch. The platform provides policy templates for general, securities, healthcare, and R&D security scenarios, and allows enterprises to continue maintaining their own sensitive words, project names, internal terminology, and special rules.

Risky content does not always appear in standard text form. For different carriers such as character substitution, hidden content, encoded text, images, and QR codes, the platform first restores them to recognizable content as much as possible before proceeding to detection, reducing the bypass risk of relying solely on keyword rules.

A security judgment does not stop at a simple "allow/deny" result. What rule was hit, what action was taken, and why the request was ultimately allowed or blocked are all recorded in the runtime log, providing a basis for subsequent troubleshooting and policy optimization.

For questions that must be answered according to a unified standard, the platform can also maintain standard answers through a required-answer repository; for different types of requests, it can combine local intent recognition to route them to a more suitable model or service.

Through these capabilities, the security guardrails are no longer a check system separate from the AI invocation, but directly enter the runtime chain of a single invocation.

WASM Plugins: Leaving Room for Custom Enterprise Rules

Built-in policies cannot cover every enterprise’s full requirements. Zentrix supports mounting an enterprise’s custom logic into the gateway request-handling chain in the form of WASM plugins, to extend specific authentication, processing, and policy logic.

To prevent third-party plugins from affecting gateway stability, the platform also constrains the plugin’s compute resources, execution time, and runtime objects, so that custom logic runs within a controlled environment.

After Usage: Correlating Invocations, Changes, and Costs

Observability: Drilling Down from Aggregate Metrics to a Single Invocation

Every managed invocation can record information such as the caller, time, target model or tool, rules hit, and token consumption, and drill down from an aggregate view to invocation details.

For streaming conversations, the platform separately tracks time to first response. This is closer to the wait time perceived by the user, whereas total duration is better suited to measuring the processing of a complete request. Gateway self-time and upstream-service time are also presented separately, making it easier to determine at the fault site which layer the latency occurred in.

These two sets of metrics solve different problems: if the first response is slow, the user will directly feel "no response"; if the total duration is long, it may indicate substantial generated content or a long downstream tool chain. At the same time, looking only at end-to-end duration cannot tell whether the latency comes from the upstream model or the gateway itself. By breaking these metrics apart, troubleshooting avoids misattributing an upstream-service issue to a gateway performance problem, or vice versa.

Two Types of Auditing: Who Changed the Configuration, and Why a Call Got Its Result

Configuration auditing records who created, modified, or deleted models, MCP, Agents, credentials, and policies; runtime records explain which judgments a single invocation passed through, and why it ultimately succeeded, failed, was rewritten, or was blocked.

Recording configuration changes and runtime invocations separately yet correlating them helps the enterprise distinguish "which policy was changed by whom" from "why a request got this result," shortening the troubleshooting and forensics path.

For example, if a request is suddenly rejected, the runtime record can point out which rule it hit; the configuration audit then continues to answer who modified that rule and when. The two lines are stored separately yet correlated through policy and invocation information, enabling traceability from a fault symptom back to a configuration change—rather than dumping all events into a single log stream for manual filtering.

Cost Ledger: Breaking the Total Down to Departments, Projects, and Systems

The platform can tally usage by model, model category, project, consumer, and access system, view trends and Top rankings, and drill down to individual invocations. Finance or platform teams no longer see only a single vendor total bill, but can further trace which department, project, or business system the cost came from.

Alerts are triggered automatically based on preset thresholds and linked to subsequent remediation entry points, helping operators move from detecting an anomaly to entering the handling process.

Seeing from the Admin Console Whether Management Truly Takes Effect

The Zentrix admin console is organized into modules such as setup, organization and permissions, guardrails, quality, operations and troubleshooting, usage and cost, alerts and remediation, auditing and forensics, and system settings, each handling the before-, during-, and after-the-fact management tasks.

The overview page displays invocation volume, success rate, latency distribution, and pending alerts, helping administrators grasp the current operational state. The authentication and traffic-rules pages also separately present the control-plane configuration version and the data-plane node loading status. After an administrator submits a rule, they can not only confirm that the configuration is saved, but also further determine whether the rule has been pushed to the data plane and loaded by the nodes.

What a Unified Management Platform Ultimately Delivers

Once permissions, runtime control, security, auditing, and cost are placed into the same invocation chain, the value of Zentrix is more than just reducing a few backend configurations.

More importantly, the enterprise can begin to correlate, around a single AI capability invocation, "who acquired the capability, what was called, what judgments were passed, how much cost was incurred, and what ultimately happened."

On this basis, a unified management platform further brings several concrete changes.

First, it helps AI projects meet the governance conditions for entering production.

Moving from pilot to production, security, compliance, finance, and operations all need verifiable evidence: how sensitive data is handled, who called what, whether policies are in effect, and how costs are attributed. Zentrix turns this information into queryable, exportable records, providing evidence for project review and continuous operation.

Second, it reduces the impact of AI-capability changes on business integration.

Zentrix converges the connections between the business side and specific models and services into a unified entry point. Within the bounds of protocol compatibility, supplier switching, traffic weighting, and failover can be accomplished through configuration, reducing the workload for business systems to adapt to multiple upstreams directly.

Third, it reuses the existing management framework when adding new capabilities.

Today enterprises mainly connect models and tools; in the future, collaboration between Agents will grow. If every new capability triggers a rebuild of permissions, limits, guardrails, and auditing, the governance system will remain perpetually fragmented. With the four capability types sharing one governance language, the enterprise can reuse its existing organization, credentials, policies, and ledger as it expands its capability boundary.

Fourth, it supports privatized and offline delivery.

Zentrix supports privatized offline deployment, keeping data, model credentials, audit logs, and the token ledger within the customer’s environment. For industries with explicit requirements on data boundaries and network environments—such as finance, energy, and government—this is a foundational delivery condition.

From Fragmented Access to Unified Access and Managment

As models, MCP, Agents, and Skills continue entering business operations, what enterprises need is not just more AI capabilities, but a management approach capable of continuously absorbing them.

Through a unified entry point, Zentrix correlates fragmented capabilities, permissions, policies, invocations, audits, and costs, enabling AI capabilities to scale continuously while governance need not fragment alongside them.

Making every AI capability invocation accountable.