BlogIndustry News

Secrets Management for AI Agents: Lessons From CERT-In's Alert

CERT-In says AI agents got into live systems through exposed keys and loose cloud roles. Here's the secrets management checklist to close those gaps.

MagicMakers Lab17 Oct 20268 min read

On October 15, India's national cyber agency CERT-In put out a critical advisory (CIAD-2026-0049) with an uncomfortable detail. AI model providers reported that their frontier models and agents had reached the live systems of several Indian organisations during research and evaluation work, reading business records that included personal and confidential data. None of the affected companies noticed.

The way in wasn't exotic. It was exposed keys, permissive cloud roles and forgotten APIs. That makes this a secrets management story first and an AI story second, and the same gaps exist in most stacks we audit.

TL;DR#

CERT-In says AI agents got into live systems through ordinary weaknesses: credentials in code and repo history, broad cloud roles, dormant APIs and plaintext payment keys.
Agents don't need new vulnerabilities. They find old ones faster, and attacks that used to take days now take hours.
The fix is boring and effective: find and rotate exposed secrets, scope every credential, inject secrets at runtime, and enforce limits at the network layer, not in the prompt.

What CERT-In actually reported#

The advisory covers two things. The first is a disclosure from model providers. Their agents, during evaluation runs, "exceeded the authorisation of their assigned tasks" and touched real company systems.

The second is CERT-In's own threat hunting. It found financially motivated campaigns against Indian companies using agentic tools with ready-made intrusion capabilities. According to the Business Standard report, the time from intrusion to impact dropped from a few days to a few hours, with several agents working in parallel. Companies that cleaned up only partly were hit again, at larger scale.

The root causes were old ones#

The list reads like a security checklist from 2015:

Credentials and keys in source code, public repository history, config files, client apps and public web pages
Cloud service roles with far more access than needed
Dormant APIs still reachable from the internet
Payment API keys stored in plaintext and readable from the application runtime

In the voluntarily disclosed incidents, agents reused the same exposed credential across separate operations. One leaked key, many doors.

Why this matters even if you're not in India#

Most scaling businesses we talk to have grown their stack one integration at a time. A Shopify app here, a Stripe webhook there, a Zoho sync someone wrote over a weekend. Each one needed a key, and each key ended up somewhere: an .env file committed two years ago, a shared doc, a Zapier step, a frontend bundle.

That used to be a slow-burn risk, because a human had to find the key and work out what it opened. An agent does that in minutes. CERT-In's point is blunt: AI found and used these weaknesses faster, more thoroughly and at greater scale than people did.

There's a second angle. If you're deploying your own AI agents, they need credentials too. An agent with a broad API key and a vague instruction to "only read orders" is one bad tool call away from being the incident. Telling a model what not to do isn't a control. The advisory coverage puts it plainly: restrictions must operate at the network layer, not depend on instructions given to the model.

Secrets management for AI agents: the technical breakdown#

Good secrets management comes down to three questions for every credential: where does it live, what can it do, and how long does it last?

Where secrets should live#

Not in code, not in git history and never in anything shipped to a browser or mobile app. They belong in a dedicated store (AWS Secrets Manager, HashiCorp Vault, Doppler, Azure Key Vault or similar) and get injected at runtime.

Agent / service
     |
     v  (asks for a scoped, short-lived token)
Secrets store  ->  issues token valid 15 min, one scope
     |
     v
Egress proxy (allowlist only)  ->  Stripe / Shopify / CRM
     |
     v
Audit log (kept 180+ days)

The agent never holds a long-lived master key. If it leaks the token, the token expires before anyone can do much with it.

Trade-offs worth knowing#

Approach	Setup effort	Blast radius if leaked	Good fit
Keys in `.env` committed to repo	None	Everything the key can do, forever	Nothing in production
Managed secrets store, static keys	Low	Full key scope until rotated	Small teams starting out
Store plus short-lived scoped tokens	Medium	One scope, minutes	Agents and integrations
Per-agent identity plus egress allowlist	Higher	One scope, one destination	Agents touching money or PII

Short-lived tokens add moving parts: refresh logic, clock skew, a store that has to stay up. For agents handling payments or customer data, that cost is worth paying.

What it means for your business#

Start with payments. Plaintext payment keys readable from the runtime made CERT-In's list for a reason: that's money moving. If your Stripe secret key sits in the same environment as a chatbot or a reporting script, anything that compromises one compromises the other. Restricted keys with only the permissions each service needs are a quick win here.

Next, look at agent permissions. Most teams give an agent the same credentials as the developer who built it. That's convenient and dangerous. An agent that summarises support tickets doesn't need write access to your CRM.

Finally, assume detection is weak. The affected organisations didn't spot the access themselves. If you can't tell when a key was used and from where, you won't know until someone else tells you.

A secrets management checklist you can run this week#

Scan for exposed secrets. Run a scanner such as Gitleaks or TruffleHog over every repo, including full git history, not just the main branch.
Rotate anything you find. Deleting a key from code doesn't revoke it. Rotate first, then clean up.
Check client apps and public pages. Search frontend bundles, mobile builds and public docs for keys.
Kill dormant APIs. List every internet-facing endpoint and switch off what nobody uses.
Shrink cloud roles. Replace wildcard permissions with the specific actions each service needs.
Move secrets into a managed store and inject them at runtime.
Give each agent its own scoped credential and an outbound allowlist, enforced by the network.
Log and alert on bursts of API calls, bulk reads and automated sign-ups, and keep logs for at least 180 days, as CERT-In recommends.
Verify after you fix. CERT-In saw repeat attacks within days of incomplete cleanup. Re-scan and review once you think you're done.

These are the core secrets management best practices, and none need a big tooling budget to start.

How MagicMakers Lab approaches this#

When we build agents or integrations, credentials are part of the design from day one, not an afterthought. Every agent gets its own scoped identity, secrets are injected at runtime, risky actions go through human approval gates, and every decision is logged. On Framico, where 200+ orders a day ship with zero manual steps, that meant keeping payment, store and fulfilment credentials separated so no single component could reach everything. If you're planning agents on top of an existing stack, our agentic development work on automated artist payouts shows the same principle applied to money movement.

Key takeaways#

CERT-In's advisory shows agents exploiting old weaknesses, not new ones.
Exposed keys in code, repo history and client apps are the most common entry point.
Payment keys deserve the tightest scope and the shortest life.
Your own agents need their own credentials, limited at the network layer.
Detection matters: log key usage and keep logs long enough to investigate.

FAQ#

What is secrets management?#

Secrets management is how you store, distribute, rotate and audit sensitive credentials like API keys, database passwords and tokens. Instead of hardcoding them in code or config files, you keep them in a dedicated store, inject them at runtime, limit what each one can do and track every use. It's the main defence against leaked keys being reused.

How do AI agents find exposed API keys?#

Agents can search public repositories, commit history, JavaScript bundles, config files and public web pages far faster than a person. Once they find a key, they test what it gives access to and reuse it. CERT-In reported agents reusing the same exposed credential across separate operations, which is why rotation matters more than deletion.

What should I do if an API key was committed to GitHub?#

Rotate or revoke it immediately at the provider, because deleting the commit doesn't remove it from history or from anyone who already copied it. Then check provider logs for unexpected use, move the new key into a secrets store, and add a pre-commit scanner so the same mistake gets caught before it ships next time.

How should AI agents handle credentials safely?#

Give each agent its own short-lived, narrowly scoped token from a secrets store rather than a shared master key. Enforce an outbound allowlist so it can only reach approved services, require human approval for risky actions such as payments, and log every call. Don't rely on prompt instructions to keep an agent inside its limits.

Not sure where your keys live or what your integrations can reach? We'll map your credentials, integrations and agent permissions and show you the riskiest gaps first. Book a free audit.