An AI development platform can be a convenient place to build and run software. It can also hold the keys to services that sit outside that platform: model APIs, cloud accounts, databases and payment systems. October’s disclosed incidents put a neglected question in front of Latin American technology leaders: if a development vendor loses access to those keys, how quickly can the customer stop both the access and the bill?
Wiz Research counted at least nine AI developer platforms that disclosed security incidents during October 2026. The researchers warn that most investigations are still incomplete and that the incidents do not share a proven single cause. Their stronger, narrower finding is about the consequence of exposed credentials: in two cases linked to a compromised vendor, attackers used stolen Amazon Bedrock access at very high volume. One key saw approximately 800,000 calls over 30 hours; another saw approximately 1.7 million calls over 13 hours. Wiz estimated more than $100,000 of usage at list prices across the two cases, which is not a confirmed customer invoice. Wiz Research.
Northflank provides a useful first-party account of one vendor’s response. Its November 2 status update said the attack vector appeared contained and that its investigation had not found access to running workloads or workload data. It also said evidence pointed toward secrets in its control plane, reported unauthorized AI-secret use by some customers, and told customers to rotate all project and integration secrets and inspect provider logs. The investigation was ongoing; the company had not yet published a final root-cause report. Northflank incident notice.
These accounts do not establish how many Latin American organizations were affected. They do establish a test that applies anywhere a regional team builds on global cloud platforms: a vendor’s incident can become the customer’s cross-provider incident.
Map the credential before the emergency
The first useful artifact is a short, owned inventory of every secret stored with a development platform. Record which external service it opens, the account or project it can reach, its permissions, its spending exposure, the person who can rotate it, and the service that will break when it changes. Include test and staging environments; these often have production-capable credentials despite their names.
The inventory should distinguish a vendor session token from a cloud access key, a model-provider key and a database password. The vendor may revoke its own sessions while leaving customer-owned downstream credentials active. Northflank’s notice describes both types of action separately. A reassuring statement about workload availability does not settle the status of keys held in a control plane.
For AI access, add cost visibility to the usual security fields. A key can be abused without reading a database or encrypting a server. A sudden inference spike may be the first visible symptom. Wiz’s cases show that a brief validation call can precede a much larger wave days later. That is an observed pattern in two cases, not a universal attack timeline.
This inventory also changes how a team reads a vendor notice. A list of affected platforms is too broad to act on, while a list of the customer’s own keys in that vendor is actionable. The incident lead can immediately ask: which keys have production reach, which have permission to call paid models, which can create new resources, and which have no owner? A key that is unused should be revoked rather than rotated into another forgotten deployment.
There is a second boundary to map: who pays. Some applications use a vendor’s bundled AI credits; others place the customer’s own cloud or model-provider key in the vendor’s environment. The financial exposure is different. The first may appear on the platform bill; the second can show up in a separate provider account after the platform has already recovered. The same credential inventory should name the billing account and the person who can review its usage. Without that link, security may declare containment while finance discovers the expense later.
Turn rotation into a coordinated recovery
Rotation is necessary but it is not a single click. AWS advises revoking or rotating exposed credentials in the originating service, then updating applications that use the replacement. AWS guidance on exposed secrets and identity access controls.
For a customer using several development and AI providers, that suggests four concrete receipts:
1. Containment: disable the suspect key or session at the service that accepts it. A vendor-side password reset alone may leave an external API key usable. 2. Replacement: issue a new, narrower credential and deploy it to each dependent workload. Confirm the old credential no longer works. 3. Usage review: compare provider logs, call counts and spend against the normal workload, including the days before the public notice. Preserve the evidence needed to dispute or explain abnormal usage. 4. Continuity: verify the application and its background jobs after rotation. A secret can be safely revoked while a forgotten worker silently fails.
Teams should rehearse this sequence before the next notice. Time the exercise from vendor alert to revoked downstream access, restored workloads and a reconciled usage record. If the key owner, billing owner and deployment owner sit in different organizations, put those handoffs in the runbook.
NIST’s current incident-response guidance puts preparation, detection, response and recovery within ordinary cybersecurity risk management. The rehearsal is a way to make those responsibilities visible across a vendor boundary, rather than treating the vendor notice as the entire response. NIST SP 800-61 Rev. 3.
The exercise should begin with a plausible but incomplete alert. The development vendor says it is investigating unauthorized access to its control plane. It cannot yet say whether one customer’s secrets were read. Give the response team 30 minutes to identify the exposed keys, decide which can be revoked immediately, and assign owners to the others. Then inject an anomalous AI-usage graph from the downstream provider. The point is to learn whether the team can act under uncertainty, not to wait for a final vendor report.
Measure elapsed time and evidence quality separately. A fast blanket rotation that breaks a payment integration is not a clean recovery. A careful investigation that leaves a high-privilege AI key active for hours is not a clean recovery either. The target is a staged sequence: revoke or restrict the highest-risk credential, replace it through a controlled deployment, confirm that the old credential is denied, and reconcile the external usage record. Record each step with an owner and timestamp. Those receipts are more useful than a vague statement that the team “rotated secrets.”
Do not confuse an API quota with a full spending control. Quotas may slow a flood, as Wiz observed in one of its cases, but they may also permit substantial usage before a human notices. A practical control stack combines least-privilege access, provider-side anomaly alerts, budget thresholds, and a tested ability to disable the credential. The exact controls vary by provider and contract; the operating requirement is that the customer can act without waiting for a ticket to cross several support queues.
The decision for regional buyers
The procurement question for a Latin American CIO or CISO is not whether an AI development platform can promise perfect security. It is whether the organization can see and limit the damage when that platform’s credential boundary fails. Require an exportable secret inventory, clear vendor incident notices, scoped credentials, provider-side usage alerts, a tested rotation path and an identified billing escalation contact.
Regional teams often depend on a global vendor, a local integrator and a separate AI provider. That makes ownership especially easy to blur. The contract and runbook should say who receives the vendor alert, who can revoke the downstream key, who can confirm whether workloads recovered, and who can contact the billed provider. If any of those roles is implicit, test the handoff before production expansion. This is a governance inference from the incident pattern, not a claim that Latin American customers were part of the disclosed cases.
Wiz’s evidence makes AI usage fraud a financial control problem as well as a security problem. Northflank’s notice shows why the customer must act even while a vendor continues its investigation. The practical measure of readiness is simple: can the team revoke the right external keys, restore service and account for the meter before an attacker turns a stolen secret into a sustained expense?