On September 10, Anthropic released its latest AI risk report: Detecting and countering misuse of AI: September 2026. The report documents multiple incidents involving AI credential leaks and unauthorized use. For enterprises deploying models and agents, these cases offer a starting point for reviewing their day-to-day integration and management practices.
After integrating models, getting APIs working, and launching applications, several questions still need to be answered: Who holds the API keys? Which models can each application use? How are permissions revoked once a project ends? And when billing anomalies arise, can you trace them back to the specific application and owner responsible?
An API key connects an enterprise's model access rights to its usage quota. Bringing credential protection into pre-launch checks — and continuously managing authorization and usage during operations — helps reduce the chance of leaks while also preparing you to handle anomalies.
The cases in the report can be grouped into four scenarios, based on where credentials are exposed and the environment in which they are used: application release, model integration, automated evaluation, and client-side usage.
01 / RISK SCENARIOS
Four Credential Exposure Scenarios in Anthropic's Report
01 | Credentials exposed with code and applications
The report notes that some users accidentally left API keys or session tokens in public code, application files, container images, and websites. As this content was published externally, information originally meant for business authentication entered externally accessible territory, where others could obtain and use it. In these cases, the exposure occurred during software delivery: credentials leaked out together with code, configuration, or application files, moving beyond their original internal scope of use.
02 | Model proxy services affected by untrusted instructions
The report records that some AI proxy services were affected by prompt injection, causing production API keys in the runtime environment to leak. These services handle the connection between applications and models, and the credentials they hold are tied to upstream model access rights. Unlike accidental exposure in public files, these incidents occurred while the service was running. The influence of untrusted content on system behavior further spread to the sensitive credentials accessible within the environment.
03 | Automated evaluation environments leaking production credentials
In one incident disclosed in the report, an AI vendor's automated evaluation sandbox was affected by malicious instructions and leaked the production API keys it held for multiple model providers. This case involves the connection between evaluation tasks and production resources. The evaluation took place in a sandbox, but the API keys accessible within that environment corresponded to actual model services — so the impact extended to the resources associated with those credentials.
04 | Credential risks from untrusted AI services and clients
The report also covers activities that promote low-cost model access and obtain user credentials through counterfeit clients. In some cases, malicious programs on user devices continuously acquire new session credentials, with the risk persisting as the client is used. Compared with the first three categories — which occur in code, services, or evaluation environments — these incidents begin at the point where users choose a service and install software. Credential security is therefore tied to software provenance, device state, and day-to-day usage behavior.
These four scenarios involve different exposure points and usage environments, collectively showing that credential risk can emerge at multiple stages: delivery, integration, evaluation, and everyday use. Once an API key is linked to a production service, its use affects the enterprise's access rights, usage quota, and account records — management after initial configuration matters just as much. Enterprises need to bring the entire lifecycle of API keys — creation, allocation, usage, rotation, and revocation — under management. Preventing leaks, detecting anomalies, and investigating and remediating incidents must be connected so they keep working as the business changes. As the number of integrated applications and teams grows, this also places higher demands on the original, decentralized approach to management.
02 / CREDENTIAL MANAGEMENT
The More Applications Users Have, the More Obvious the Problem of Decentralized API Key Management
These credential risks span software delivery, third-party services, and AI runtime environments. For enterprises, this means the scope of protection must cover the entire credential lifecycle — from creation and allocation to usage and revocation.
In the pilot phase, a team applies for an API key and completes integration, and the application typically works. But as more departments deploy models and agents, the practices that made a project easy to get off the ground may leave behind long-term management problems.
First, credentials become scattered, making it hard to maintain a complete inventory. Different projects apply for and store API keys separately, followed by staff handovers, environment migrations, and application upgrades. Without unified records, it's hard for platform teams to confirm which credentials are still in use and which have lost a clear owner.
Second, shared usage makes it difficult to distinguish the source of calls. When multiple applications or people share one set of credentials, the records on the account tend to blur together. After an abnormal charge is discovered, security and operations teams must verify with each project one by one — delaying investigation and increasing the risk of mistakenly disrupting legitimate business.
Third, permission revocation tends to lag behind business changes. Staff transfers, project closures, and vendor changes can all alter existing access needs. If credentials remain valid, permissions that are no longer needed will stay in place.
As agents begin calling tools and accessing enterprise systems, the objects to manage will keep growing. Enterprises need to know not only which models an application can use, but also which operations an agent can perform. If each project maintains its own configuration, unified adjustment and inspection will become increasingly difficult.
Therefore, enterprises need to bring credential management into a shared integration standard: keep real API keys centrally stored as much as possible, grant each application permissions as needed, tie usage records to specific owners, and establish a clear entry point for permission changes.
03 / ZENTRIX GOVERNANCE
Unify Access Through Zentrix, and Let Governance Keep Pace with the Scale of AI
For enterprises that have already integrated multiple models, applications, and agents, model calls can be organized as:
Application / Agent → Zentrix → Model Provider
In this architecture, applications use enterprise-issued access credentials to reach Zentrix, and Zentrix uses managed upstream API keys to complete model calls. The integration and management work previously scattered across projects gains a unified entry point.
Reduce the Distribution of Real API Keys, and Make Permissions Adjustable Per Application
Zentrix centrally manages model providers' API keys, so business applications and agents do not need to directly hold real upstream API keys. The credentials used by each integrator can have a validity period and can be revoked. This lets enterprises handle business changes more precisely: when a project ends, its access can be revoked; when an application's access credential is suspected of being leaked, it can be handled individually; when a model provider's API key needs to be rotated, it can be adjusted through a unified entry point — reducing the work of modifying each business configuration one by one. Combined with unified authentication and model access control, enterprises can allocate permissions according to the actual needs of organizations, users, and applications — reducing the situation where multiple business units share one set of credentials for the long term. Credentials still need to be properly protected, but there is now clearer management grounding for who is using what, what they may use, and when access should be revoked.
Bring Agents and Tools Under the Same Set of Management Rules
Once agents are integrated into enterprise systems, model calls further drive tool execution. Enterprises need to extend management requirements to these operations — clarifying which capabilities are allowed to be integrated, to whom they are exposed, and whether authorization is obtained at the time of actual invocation. Zentrix can bring agents, MCP servers, and tools into a unified catalog, and before a tool executes, it checks the caller's identity, authorization scope, and tool status. When a tool definition changes, a re-review can be triggered. In this way, platform teams can open up AI capabilities within a shared management framework, and business teams have a clearly defined scope of use. When a new agent is integrated or a tool is updated, the associated permissions can be checked and adjusted accordingly, reducing omissions caused by long-standing reliance on outdated configurations.
Link Abnormal Consumption to Specific Calls
Credential protection also requires continuous checks during operation. Beyond reducing the chance of leaks, enterprises also need to identify affected applications as quickly as possible after an anomaly occurs and limit further losses. Zentrix can view call volume, token consumption, and cost by project, user, and integrated system, and alert based on preset thresholds. Request rate, token rate, and concurrency limits help enterprises constrain a single caller's resource usage and reduce the impact of abnormal traffic on other business. A rise in call volume may come from business growth, or from repeated program calls or credential abuse. To determine the cause, you need to analyze usage changes together with specific requests. Zentrix's call tracing and audit records help platform teams trace the initiator, permission decisions, and execution results — providing a basis for subsequent remediation. From detecting an anomaly, to locating the application, to adjusting permissions or revoking access, enterprises gain a clearer path for handling incidents. The associated records can also be used for post-incident review, driving continuous improvement of usage rules and management processes.
04 / AI SECURITY
AI Security Requires Technology, Processes, and People Working Together
Credential governance is a key part of enterprise AI security. To keep it effective over the long term, you need to plan systematically in advance and implement requirements across procurement, development, launch, and day-to-day use. NIST's AI Risk Management Framework incorporates role assignments, employee training, continuous monitoring, and periodic assessment into its governance requirements. The UK National Cyber Security Centre (NCSC) also emphasizes that AI security requires organizational culture, processes, and communication working together, spanning system design, development, deployment, and operation.
For enterprises, the first step is to clarify responsibility. Every AI application should have a clear owner, and there should be concrete rules for which services are approved, what data may be processed, and which operations require human confirmation. Business, security, and operations teams need to participate together, to avoid adding management requirements only after launch.
Architecture design should consider permission and data boundaries in advance. Test and production environments should be separated by purpose, and applications and agents should be authorized according to task needs. When models, tools, or vendors change, you should also reassess whether existing configurations remain appropriate.
Employee training is equally critical. Employees need to understand approved AI services and data usage requirements; developers need to master the basic standards of credential protection; and operations and security teams need to be familiar with anomaly investigation and emergency response. Only by conducting training and drills based on real cases can relevant personnel know how to act when problems arise.
After launch, enterprises should also regularly review assets and permissions, check whether credentials that are no longer in use have been revoked, and continuously improve processes through incident reviews.
Governance needs to change along with the way AI is used. Zentrix provides a unified AI control plane for this system, enabling the governance rules an enterprise has established to be continuously enforced in daily use. As more teams and agents are integrated, enterprises can expand applications within a shared management framework, reducing the discrepancies and omissions caused by each project managing things on its own. Only when platform capabilities are paired with institutional development, staff training, and continuous improvement can they better support the large-scale application of AI.
If an AI API key were stolen today, when would an enterprise find out — when anomalous invoke occur, or when the bill arrives?
From detecting the anomaly to locating its source and stopping losses in time, every step requires advance preparation.
Welcome to talk with the ZStack team about how, in the context of your existing AI applications, Zentrix can bring credential protection and call governance into day-to-day operations.