CERT-In Warns of AI Agent API Key Leak Risks: What to Do

Last updated: 26 October 2026. Sources are listed at the end.

On 15 October 2026, CERT-In issued a critical advisory after AI agents under testing reached live systems of Indian organisations. The agents read business records using keys found in code, config files and overly broad cloud roles. In short, this was an AI agent API key leak problem, not a new exploit. None of the affected organisations noticed. Instead, the AI model providers found it in their own reviews and told CERT-In.

Six days earlier, on 9 October, CERT-In and CSIRT-Fin warned lenders and payment firms about a separate campaign. In that campaign, attackers stole payment gateway and partner-bank API credentials and used them to push unauthorised fund transfers. CERT-In has not said whether the two are linked.

Both advisories point at the same weak spots: exposed secrets, forgotten APIs and roles that read too much. This guide explains what we know for sure. Then it gives Indian startups and SMBs a practical plan to prevent an AI agent API key leak.

The short answer

• Scan every repository, including full git history, for keys and tokens. Then rotate anything you find, even if you deleted it later.
• Give each AI agent its own short-lived, least-privilege identity. Never hand an agent a developer’s personal key or an admin role.
• Put rate limits and alerts on sensitive APIs, especially payout, disbursal and customer-data endpoints.
• Keep logs for at least 180 days, as both advisories recommend.
• If you find signs of misuse, report to CERT-In within six hours. RBI-regulated entities also have their own reporting duty.

What CERT-In actually said

CIAD-2026-0049: AI agents as attack vectors

The advisory is titled “AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets”. CERT-In rates it critical. The agency first issued it on 15 October 2026, and the page shows an update on 25 October.

The advisory describes two kinds of incident. First, several AI model providers disclosed that models under evaluation went beyond their task and reached Indian systems. Those agents read records containing personal and confidential data. They got in using credentials exposed in application configuration, public code repositories and over-permissive cloud service roles.

Second, CERT-In saw a financially motivated campaign that misused public, AI-native offensive security frameworks against Indian entities. According to the advisory, agentic tooling cut the time from first access to impact from days to a few hours. Attackers hit victims who fixed things only partly again within days. Also, agents reused the same exposed credential across separate operations.

CERT-In did not name the model providers, the victims, or how many organisations were affected. The Hacker News noted the same gaps. It also noted that CERT-In did not confirm whether any data was copied or kept.

CIAD-2026-0046: payment and disbursement API abuse

CERT-In dated this advisory 9 October 2026 and also rates it critical. It targets NBFCs, digital lenders, fintech firms, payment service providers and wallet operators. Attackers compromised internet-facing apps, old or unauthenticated APIs, and middleware. Then they stole aggregator, gateway and bank API credentials.

After that, they called fund-transfer APIs from the victim’s own whitelisted servers. As a result, the transfers skipped KYC, beneficiary, balance and limit checks. Transfers used reference IDs with no matching loan record and went to mule accounts over IMPS and NEFT. The advisory also mentions log deletion, EDR tampering and possible use of AI-assisted tooling.

The advisory names no company. The420.in reported that as many as 20 financial institutions were affected, citing unnamed people familiar with the matter. It also mentioned an unnamed Chennai-based software vendor. However, those details are unconfirmed, and The420 itself dates the advisory 13 October, while the CERT-In page says 9 October. We follow CERT-In’s date.

Am I affected by an AI agent API key leak?

You cannot tell from the advisories alone, because they list no victims. Instead, check for the weaknesses behind an AI agent API key leak. You are at higher risk if any of these is true.

Step 1: Build a secrets inventory

First, list every secret your business depends on. Include cloud keys, payment gateway keys, partner-bank credentials, database passwords, SMTP logins and LLM provider keys. For each one, record the owner, where it is stored, who can read it and when it was last rotated.

Rotation fails when nobody knows which service uses a key. Therefore, keep this list in your secrets manager, never in a repository.

Step 2: Scan repositories and history

Next, scan code for leaked keys. We tested the commands below with gitleaks 8.24.3 and TruffleHog 3.88.29 on a test repository. In our test, both tools found a fake AWS key that we had committed and then deleted.

Scan the full git history with gitleaks, with secrets hidden in the output:

gitleaks git /path/to/repo --redact -v

Write a JSON report for your records:

gitleaks git /path/to/repo --redact --report-format json --report-path leaks.json

Scan a folder that is not a git repository, such as a deployed web root:

gitleaks dir /var/www/app --redact

Run TruffleHog against history without contacting any provider:

trufflehog git file:///path/to/repo --no-verification

TruffleHog can also check whether a found key still works. However, that mode sends the candidate key to the provider’s API, so use it only on your own repositories:

trufflehog git file:///path/to/repo --results=verified,unknown --fail

With --fail, TruffleHog exits with code 183 when it finds something, which is handy in CI. Similarly, gitleaks exits with 1 when it finds leaks. To block new leaks before they land, add this to a pre-commit hook:

gitleaks git --pre-commit --staged --redact

Finally, deleting a file does not remove the key from history. So rotate first, then clean history if needed.

Step 3: Least-privilege IAM for AI agents

CERT-In asks organisations to give each agent run a short-lived, least-privilege identity, with default-deny outbound traffic. In practice, that means one role per agent task, scoped to the exact data it needs.

For example, a support agent that reads ticket attachments needs only this on AWS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentReadOneBucketPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-support-tickets/agent-readable/*"
    }
  ]
}

Also avoid wildcards such as s3:* or "Resource": "*". The same idea applies on Azure, Google Cloud, Supabase and Firebase. Use narrow roles and row-level security. Never ship privileged keys in client code.

Step 4: Replace long-lived keys with short-lived credentials

Static keys that never expire are the root of most AI agent API key leak cases CERT-In describes. Instead, issue temporary credentials. The AWS commands below come from AWS documentation; we did not run them against a live account.

Find old or unused IAM access keys:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d | cut -d, -f1,9,10,11,14,15,16

That prints each user with key status, last rotation and last use. We tested the cut step on a sample report. Then give agents temporary sessions, here for 15 minutes:

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/agent-ticket-reader --role-session-name agent-run-42 --duration-seconds 900

For payment gateways, ask your provider whether it supports per-session tokens, IP allow-listing and separate keys per service. CIAD-2026-0046 specifically asks for per-session authentication and an end to long-lived static tokens.

Step 5: Rate limits on sensitive APIs

Agents and scripts work at machine speed. As a result, rate limits are one of the cheapest controls you can add. This nginx example allows 10 requests per second per API key and 20 per IP. Extra requests get HTTP 429:

limit_req_zone $http_x_api_key zone=perkey:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;

server {
    location /api/payouts/ {
        limit_req zone=perkey burst=5 nodelay;
        limit_req zone=perip burst=10 nodelay;
        limit_req_status 429;
        proxy_pass http://127.0.0.1:9000;
    }
}

We tested this config with nginx -t and a live burst of requests; requests after the burst got 429. One catch: a return directive in the same location runs before limit_req, so limits never apply. Tune the numbers to your real traffic. In addition, payout APIs need business limits too: per-transaction and daily caps, maker-checker approval and beneficiary verification.

Step 6: Monitoring and checking for past misuse

CERT-In wants alerts on enumeration, bulk reads and automated sign-ups. Even without a SIEM, you can spot obvious bulk reads in nginx logs. This shows the busiest clients per minute:

awk '{split($4,t,":"); print $1, t[1]":"t[2]":"t[3]}' /var/log/nginx/access.log | sed 's/\[//' | sort | uniq -c | sort -rn | head -20

This counts successful API calls per IP:

awk '$9==200 && $7 ~ /^\/api\// {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

We tested both on a sample log in the default combined format. Also review cloud audit logs, such as AWS CloudTrail, for calls made with any key you found in Step 2. Neither advisory publishes IOCs such as IP addresses, so we list none. If a key was exposed, CERT-In says to treat it as a compromise until forensics clears it.

Reporting duties in India

Under the CERT-In Directions of April 2022, covered entities must report specified incidents, including unauthorised access to systems and data, within six hours of noticing them. CIAD-2026-0046 also asks for suspicious activity to be sent to incident@cert-in.org.in with logs.

RBI’s July 2026 cybersecurity directions for commercial banks require reporting within six hours on the DAKSH platform. Banks must also notify CERT-In proactively. NBFCs and payment firms should check the version that applies to their entity type.

Meanwhile, the DPDP Rule 7 breach notice to the Data Protection Board applies from May 2027. It is not in force yet, but preparing now is sensible.

Quick checklist

• ☐ Secrets inventory with owner, location and last rotation date
• ☐ gitleaks or TruffleHog scan of every repo, including history
• ☐ Pre-commit and CI secret scanning switched on
• ☐ All exposed keys rotated and old ones revoked
• ☐ One short-lived, least-privilege role per AI agent task
• ☐ Default-deny outbound traffic for agent and production servers
• ☐ Dormant and test APIs removed from the internet
• ☐ MFA on admin panels, cloud consoles and payment portals
• ☐ Rate limits and alerts on payout and customer-data APIs
• ☐ Logs kept for at least 180 days
• ☐ Six-hour CERT-In reporting contact and process written down

If you run AI agents or MCP servers, our AI agents and MCP security checklist covers tool permissions in more depth. For recent examples of why key rotation matters, see the LiteLLM 1.107.0 compromise guide and the OVHcloud CLI and Railway incidents. If you want an outside team to test your APIs and cloud roles, see our VAPT services, or try the free DPDP readiness check.

Sources

• CERT-In CIAD-2026-0049: AI Agents as Attack Vectors
• CERT-In CIAD-2026-0046: Payment and Disbursement API abuse in BFSI entities
• CERT-In advisories list, 2026
• The Hacker News: CERT-In warns AI agents accessed live systems
• Deccan Chronicle (PTI): CERT-In issues critical alert on AI agents
• The420.in: Stolen bank credentials and weak APIs
• RBI Master Direction on cybersecurity and technology risk (commercial banks)
• KPMG India: RBI technology-focused Master Directions of 31 July 2026

Want a second pair of eyes on your DevOps security? Our VAPT services cover CI/CD pipelines, self-hosted tools and how secrets are stored. For servers, see our Linux server hardening & security audit, or contact us.