An engineer encounters a difficult-to-diagnose program error.He copies the code into ChatGPT and clicks send. Within seconds, the model provides an answer.The problem may be solved, but something far more serious has already happened: the company's internal source code has been sent to an external AI service.This is not a hypothetical scenario.
Case: In 2023, Samsung's semiconductor division was reported to have experienced three similar incidents. Employees submitted internal source code, equipment test information, and meeting notes to ChatGPT in order to modify code, optimize test procedures, and organize meeting minutes.
This not only caused enterprise core information to slip out of its original control boundaries but could also provide attackers with clues to analyze system architecture and identify security weaknesses—further triggering a chain of risks inclding intellectual property leakage, data compliance violations, and legal liabilities. A seemingly routine AI usage could escalate into a serious corporate security incident.
Today, AI usage is accelerating into daily enterprise business operations, but the corresponding security controls have not kept pace. Risks such as sensitive information leakage, unauthorized access, prompt injection attacks, and tool mis-invocation are becoming real security challenges that enterprises must confront.
When an Agent can read enterprise knowledge bases, access business systems, invoke tools, and execute operations, a single uncontrolled AI call could carry away sensitive data, overstep user permissions, or trigger real business actions.
What makes this even trickier is that these requests may appear entirely "normal" to the system: authentication passed, API call succeeded, model returned successfully. By the time the enterprise discovers anomalies from logs, the data has already been sent out and the operations have already been completed.
Therefore, strengthening AI security governance must be placed on the agenda—and security controls must occur before the actual model invokation is made.
ZStack Zentrix uses the AI Gateway as the unified security entry point, embedding identity verification, permission control, security guardrails, sensitive content detection, tool governance, and audit traceability into the model invoke chain. It identifies and intercepts risks before data is sent, tools are executed, and business operations are triggered—while maintaining a complete trail of all normal calls.
The entire security control chain answers four questions:
Who is calling?
↓
What data is allowed to flow?
↓
What can AI execute?
↓
Can the entire process be reconstructed?
01 / IDENTITY & CREDENTIALS
Unified Identity & Credentials: Establishing a Verifiable Call Origin
Consolidating Access Credentials, Controlling the Entry Boundary
When models and Agents are only piloted in a few projects, teams may directly use vendor API keys or shared service accounts to complete integration. As usage expands, the same set of credentials can easily appear in code, scripts, personal environments, and application configurations.
This directly creates two problems. On one hand, the enterprise cannot accurately determine which organization, user, or application a particular call originated from. On the other hand, when projects end, or credentials are leaked, the platform struggles to quickly revoke permissions without affecting other business operations.
Zentrix manages user access credentials through a unified entry point and controls the access scope through mechanisms such as access groups, IP allow-lists, validity periods, and instant revocation.
In a multi-tenant environment, users, access credentials, and AI resources can be isolated by tenant—one tenant's requests cannot access another tenant's models, Agents, tools, or configurations.
The real keys for models and tools are centrally managed by Zentrix; applications and Agents do not need to hold them directly, reducing the risk of key proliferation and leakage.
Organization / User / Application
↓
Enterprise-manageable access credentials
↓
Zentrix performs identity & access scope determination
↓
Use managed model or tool credentials per policy
Identity Pass-Through: Maintaining a Complete Chain of Accountability
For ordinary model invoke, unified credentials can help enterprises identify the request source. For Agent and MCP tool calls, it is also necessary to ensure that the real user's identity is not lost across multi-level call chains.
A user initiates a task through an Agent; the Agent then calls an MCP Server, which finally uses service credentials to access a database or business interface. If the end system only sees a shared service account, multiple users' behaviors are collapsed into a single technical identity.
Zentrix passes the real user's identity through the Agent, MCP, and tool call chain via short-lived tokens and encrypted identity pass-through:
User A initiates a task
↓
Zentrix confirms identity and forms a short-term identity credential
↓
Agent requests to call an MCP tool
↓
Tool call is associated with User A's real identity
Short-term credentials reduce the risk of long-term credentials being copied and abused; identity pass-through ensures that downstream systems see not just "a certain Agent" or "a certain application," but can trace back to the real model user.
Unified access and identity pass-through do not automatically make all invokes secure, but they provide the starting point for subsequent decisions: only when the enterprise knows where the request came from, which tenant it belongs to, and which user it represents can it proceed to determine whether data can flow and whether operations can be executed.
The first step in AI security is giving every call an identifiable source—and ensuring that real identity persists throughout the entire model invoke chain.
02 / CONTENT & DATA SECURITY
Content & Data Security: Controlling Sensitive Information Flow
After confirming the users's identity, it is also necessary to determine whether the content and data in the request can continue to be transmitted.
Employees may paste ID numbers, bank card numbers, medical records, or access credentials into prompts; business applications may also splice customer data, internal documents, and system context directly into model requests. Model outputs may contain content that does not meet business requirements, or may reproduce sensitive fields from the context.
Zentrix provides bidirectional content security guardrails—both inbound (entering the model) and outbound (returned by the model)—executing policy decisions on requests and responses. When encountering unknown or unverifiable security states, the default is to apply stricter handling, preventing silent pass-through after security detection failures.
For personally sensitive information, Zentrix uses built-in rules and local detection models to identify data types including identity, financial, medical, tax, and credential information, and performs different actions based on business scenarios:
Allow — Confirmed as meeting current usage conditions; proceeds normally to subsequent calls
Audit — Allows the call while recording what was matched
Redact — Replaces sensitive fields before continuing transmission
Block — Terminates the current call, preventing data from continuing outbound
These detection capabilities can run directly within the enterprise's internal network. Sensitive content does not need to be sent to external review services for identification; content and PII checks can continue to be performed in private or air-gapped environments.
Model invoke security govermance must answer not only "who can use the model" but also "which data is allowed to flow along this model invoke chain."
03 / AGENT & TOOL SECURITY
Agent & Tool Security: Controlling Execution Permissions Before Action
Knowing who is calling and what data can flow still does not mean a tool operation can be executed directly.
When an Agent further accesses MCP tools and enterprise systems, Zentrix must also answer three questions: does the current user have the right to perform this operation, is the tool still trustworthy, and will the request reach locations it should not access.
Single Permission Decision: Determining Whether the Current Operation Is Permitted
For Agents and MCP tools, Zentrix separately controls "who it is opened to" and "whether it is permitted for this call."
On the management side, administrators can configure which departments, functional groups, and users an Agent, MCP tool, or other capability is opened to. When a user actually initiates a tool call, Zentrix combines the real caller, tenant boundary, and the user's relationship with the target resource to make a permission decision for the current operation. Unauthorized requests are rejected at the gateway layer and do not proceed to access downstream tools and business systems.
Management: Which departments, groups, and users is this tool opened to?
↓
Runtime: Does the current user have the right to perform this operation on the target resource?
↓
Allow the call, or reject before execution
For example, a database query tool can be opened to the R&D department, but when an R&D engineer actually invokes it, the system still needs to determine whether they have the right to access the target database or the corresponding data scope. Being within the available range does not equate to having a universal pass to all resources.
Zentrix does not replace the enterprise's existing IAM and business system permissions. Instead, it brings real user identity and fine-grained call-level decisions to the execution entry point of Agents and tools, then connects them with the enterprise's existing organizational, identity, and resource relationships.
Tool Drift Re-verification: Continuously Confirming Tool Trustworthiness
A model invoke may have the correct identity and permissions, but the tool itself may have already changed.
An MCP tool's name, description, parameters, and capability definitions can be continuously updated, and these changes affect how the Agent understands and selects the tool.
Imagine a tool that has already passed assessment and initially only provided "query orders" capability. After an update, it adds "cancel orders" or "delete records" parameters while still using the original name and access address. If the platform only performed a one-time approval at initial onboarding and continues to use the original trust status, the tool's actual risk boundary may have already shifted.
Zentrix checks for tool definition changes through tool drift re-verification. When security-relevant content changes, the original admission status needs to be re-confirmed; tools that have not completed re-verification are not allowed to continue.
Tool first onboarded → Security assessment → Admission granted
↓
Tool definition changes
↓
Trigger re-verification → Re-approve or reject
For enterprises that connect to external MCP Servers, frequently update internal tools, or allow Agents to operate production systems, tool security cannot stop at one-time registration. Tools change continuously, and security admission must also be ongoing.
Inbound & Outbound Protection: Constraining the Network Boundary of Requests
An AI call carries not only identity, content, and data but also generates real network requests.
Requests entering the gateway or web interface may contain common attack payloads; outbound requests from Agents, tools, or server-side may be induced to access unexpected addresses, probe internal network services, or reach endpoints the enterprise does not permit through redirects.
Zentrix's Web Application Firewall checks requests entering the interface, reducing the risk of common web attack payloads penetrating further into business systems. SSRF outbound protection constrains the targets and network ranges that server-side and tool requests can access, preventing them from reaching unexpected internal network resources or high-risk addresses.
External or business request → Web security check → Zentrix
Agent / Tool → Outbound access check → External interface or enterprise system
Correct identity and compliant data are only necessary conditions for a secure call. Whether the operation is authorized, whether the tool is trustworthy, and whether the target address is safe all need to be confirmed before execution.
True AI execution security is not just knowing what the Agent did afterward, but determining whether it can act before the action occurs.
04 / FULL-CHAIN AUDIT
Full-Chain Audit: Reconstructing Security Decisions and Execution Results
Pre-call controls solve "can it be executed"; audit must also answer "why was it decided this way at the time."
If records only contain request time and interface status codes, the enterprise still cannot reconstruct a model or Agent behavior. Complete security evidence needs to correlate key context across the call chain:
1. Which organization, user, or application the request came from, and which Agent handled it
2. Which model, MCP Server, tool, or enterprise resource was called
3. Why this call was authorized, or why it was rejected
4. Which content, PII, web, or outbound security policies were matched
5. Whether execution ultimately succeeded, and whether redaction, blocking, or other handling occurred
6. What configuration changes occurred to relevant capabilities and policies before and after the call
Zentrix separately records management operations and runtime capability calls, then correlates them through call identity, request, and resource information. Platform teams can trace back from an anomalous request to the real initiator, permission decision, security handling, and execution result, or review related call records from a tool or policy change.
Accountability is not about saving one more log—it is about being able to reconstruct the complete process of an AI call from identity, through decision, to execution result.
05 / COMPREHENSIVE COVERAGE
Enabling Security Controls to Cover Every AI Call
The security targets Zentrix faces are not just Agents, nor just the inputs and outputs of large models.
It revolves around a single AI call and sequentially answers four questions: who is calling, what data can flow, what can AI execute, and can the entire process be reconstructed.
Confirm identity: Identify call source, tenant, and real user
↓
Check data: Process input, output, and sensitive information
↓
Control execution: Determine permissions, tool status, and network boundaries
↓
Leave evidence: Record decision basis, handling actions, and execution results
For enterprises that have already integrated multiple models, or are using Coding Agents, self-built Agents, and third-party Agents, they can check their existing security chain against these four questions:
1.Can each call identify the organization, user, application, and tenant? Can the real caller be traced through to the tool side?
2.Can model input/output and sensitive data be checked, redacted, and blocked locally?
3.Can tool calls complete permission decisions, drift re-verification, and network boundary checks before execution?
4.After a security incident, can the enterprise identity, decisions, handling, and execution results be fully reconstructed?
If any of these links still relies on application-level configuration or post-incident manual investigation, it may be time to consider upgrading the existing AI security governance approach.
From Access, Governance, Cost to Security: Zentrix's Enterprise AI Control Loop
Looking back at the entire series, four articles respectively answer four key questions in enterprise AI scaled deployment:
Overview: Consolidating models, Agents, and tools through a unified entry point to regain control over AI
Governance: Unified catalog, distribution, scheduling, and observability—making AI capabilities operable resources
Cost: Making usage attributable and budgets effective before calls are made
Security: Making model requests and tool executions controllable and traceable
These four parts together form the complete product logic of the Zentrix AI Gateway
From a single entry point consolidating model, Agent, and tool, establishing usage order through continuous operations, guarding cost boundaries through metering and quotas, and then securing every AI model invoke through identity, permission, content, data, and behavior controls.
When model invoke, Agent access, and tool executions can all be identified, judged, controlled, and traced, the enterprise has truly brought continuously growing AI traffic into a manageable, controllable, and auditable production system.
If your enterprise is facing challenges such as multi-model integration, Agent tool governance, cost runaway, or unclear security boundaries, please contact ZStack to schedule a Zentrix product consultation and demonstration. We will work with your existing AI architecture to provide an integrated AI control solution covering access, governance, cost, and security.