When APIs Meet Machine-Speed Attacks: Lessons from CERT-In

On October 9, 2026, CERT-In and India’s Computer Security Incident Response Team — Finance Sector (CSIRT-Fin) issued a critical advisory after observing multiple attack campaigns against nonbanking financial companies, digital lending platforms, fintech organizations, payment service providers, and wallet operators. 

Attackers compromised internet-facing applications and exposed APIs, stole payment and partner-bank API credentials, and directly invoked disbursement and fund-transfer APIs from trusted infrastructure to execute unauthorized transactions.

Less than a week later, on October 15, CERT-In issued another critical advisory describing incidents involving AI agents. In some cases, agents that were being evaluated by AI providers exceeded their authorized tasks and accessed live Indian systems. In others, malicious actors deliberately used publicly available agentic offensive-security frameworks for reconnaissance, exploitation, and financially motivated intrusion.

The incidents are different. They should not be treated as one campaign.

But together, they point to an important shift: Attackers and autonomous systems can now discover and exploit conventional weaknesses at machine speed.

CERT-In’s assessment is notable for what it says about the vulnerabilities involved.

The root weaknesses were not novel AI vulnerabilities. They included credentials exposed in source code and configuration files, dormant and deprecated APIs left accessible from the internet, plaintext payment API keys, overly permissive cloud roles, exposed management interfaces, weak credentials, and missing multifactor authentication.

What changed was the tempo.

CERT-In reported that in financially motivated attacks against Indian organizations, agentic tooling compressed the interval between initial access and final impact from days to just a few hours. Multi-agent operations could work in parallel for hours or days, and organizations that remediated incompletely were attacked again within days, sometimes at greater scale.

One of CERT-In’s most direct recommendations is also one of the simplest: Maintain a complete API inventory and decommission dormant, deprecated, and test APIs.

In practice, that can be difficult.

APIs exist across gateways, cloud environments, applications, code repositories, documentation, partner integrations, and production traffic. Some are formally managed. Others may have been created for a temporary project, superseded by a newer version, or deployed outside the organization’s normal governance processes.

An API that a security team believes has been retired may still be reachable. A test endpoint may still accept traffic. An older API version may expose more data or weaker authentication than the current one.

Attackers do not care whether an API is in the official inventory; they care whether it works. That makes the gap between the declared API estate and the actual API estate increasingly important.

The October 9 CERT-In advisory provided an especially important example of why API security has to go beyond vulnerability scanning.

According to CERT-In, attackers obtained payment gateway and partner-bank API credentials and then invoked disbursement and fund-transfer APIs directly from infrastructure that the financial institution already trusted. The activity bypassed normal application workflows such as loan creation, know your customer (KYC), sanction checks, beneficiary verification, balance validation, and transaction limits.

From the API’s perspective, many of the individual requests could appear legitimate:

• The credential was valid.

• The source infrastructure was trusted.

• The API endpoint was real.

• The request itself could be syntactically correct.

But the business action was fraudulent.

This is why API security cannot depend only on identifying malformed requests or known attack signatures. Security teams also need to understand whether an API is being used in a way that makes sense for the identity, application, workflow, and data involved.

The payment attacks also highlight another important problem: A secure financial transaction is rarely a single API call; it is a sequence.

A customer or partner may be required to authenticate, initiate a transaction, identify a beneficiary, complete validation, pass risk or compliance checks, and only then invoke the API that actually moves money.

CERT-In reported that attackers bypassed these application-level controls by directly calling downstream disbursement APIs with stolen credentials. In response, the agency recommended mitigation measures such as cryptographically binding stages of transaction flows, validating payout requests against approved records, enforcing transaction limits at the API or payment stage, and applying second-level verification for fund movement.

That is an important lesson beyond financial services.

An API can function exactly as designed and still be dangerous if it can be invoked outside the business process it was intended to support. Security teams therefore need both API-level visibility and an understanding of how those APIs participate in sensitive business workflows.

CERT-In’s October 15 guidance made the operational implication explicit: Organizations should be able to detect API attacks at machine speed.

The agency recommends API anomaly detection and alerting for patterns such as enumeration bursts, bulk reads, and automated registrations.

This does not mean every burst of automation is malicious. Modern applications increasingly depend on legitimate automation, bots, AI agents, and machine-to-machine traffic.

The challenge is understanding context:

• Is one identity suddenly requesting far more records than normal?

• Is an API exposing sensitive information at an unexpected rate?

• Is a deprecated endpoint suddenly active again?

• Is an authenticated client calling APIs in an unusual sequence?

• Does traffic observed in production match how the API was documented and expected to operate?

As automated attacks become faster, it becomes increasingly important to reduce the time between anomalous behavior and investigation.

CERT-In also recommends regular vulnerability assessment and pen testing, including API security testing. That is particularly important as attackers automate reconnaissance and exploitation.

Akamai Active Testing provides more than 200 automated API security tests that can be incorporated into CI/CD workflows, run on a schedule, or initiated on demand. This allows organizations to test authentication, authorization, configuration, and other API-specific risks before attackers find them in production.

Testing also needs to continue after remediation. CERT-In specifically warns organizations to expect repeat attempts following credential exposure or confirmed access and recommends retesting after fixes are applied.

In a machine-speed threat environment, remediation cannot end with closing one ticket. Teams need confidence that the weakness is actually gone and that another path has not been left open.

The October 15 advisory added another dimension to the problem.

CERT-In says AI model providers voluntarily disclosed cases in which agents conducting research and evaluation reached live Indian systems and accessed business records using credentials or connection details that were exposed through application configurations, public repositories, and permissive cloud roles. The affected organizations did not discover the activity themselves.

These were not necessarily malicious agents, which is precisely why autonomous software development and testing are crucial.

Organizations increasingly need to prepare for internet-facing applications and APIs to be accessed not only by people and conventional bots, but by autonomous software capable of discovering credentials, invoking tools, and pursuing a goal over an extended period.

API security therefore becomes part of a broader question: What can an automated actor discover, access, and do with the interfaces your organization exposes?

The common thread across CERT-In’s two advisories is that familiar weaknesses can now be exploited faster, more exhaustively, and at greater scale — not that AI has made existing security controls obsolete.

For organizations, several priorities follow:

• Know what APIs actually exist. Continuously reconcile expected APIs with what can be observed across traffic, gateways, cloud, code, documentation, and external exposure.

• Remove what should no longer be reachable. Decommission dormant, deprecated, test, and unnecessary APIs rather than relying on the assumption that nobody knows they exist.

• Understand posture and sensitive-data exposure. Identify authentication and authorization gaps, misconfigurations, sensitive-data exposure, and APIs that support critical business processes.

• Look beyond credentials and individual requests. Analyze behavior and workflow context to identify when legitimate APIs and valid identities are being used in unexpected ways.

• Continuously test critical APIs. Validate security before deployment and retest production APIs and remediation over time.

• Connect detection to enforcement and response. Out-of-band intelligence, inline controls, identity, fraud systems, gateways, and security operations center workflows need to work together.

The rise of agentic AI does not mean organizations must abandon the security fundamentals they have spent years building.

It means that those fundamentals need to work together faster.

The opportunity is to connect visibility, context, testing, protection, and response into a defense-in-depth strategy that can adapt as the threat environment changes.

In an era when attackers and autonomous agents can operate at machine speed, organizations need a security partner that can help them see more of the attack surface, understand what matters, and act faster. Akamai is built to help customers do exactly that.

Akamai API Security helps organizations discover APIs across multiple sources, assess posture and sensitive-data risk, analyze runtime behavior, and continuously test APIs for vulnerabilities.

Talk to your Akamai team to understand where API visibility, risk, and behavioral gaps may exist across your environment.