Key Takeaways (TL;DR):
- Regulatory Alert: CERT-In has issued guidelines warning enterprises about insecure tool-calling permissions, indirect prompt injections, and data exfiltration through autonomous agents.
- Core Risk Vectors: Unsanitized third-party context (PDFs, emails, webhooks) manipulating agent tool arguments to perform unauthorized database writes or credential leakage.
- Defense in Depth: Enforce least-privilege API scopes, mandatory human approvals for high-impact actions, and isolated sandboxed execution environments.
AI Agent Security in 2026: What India's CERT-In Warning Means for Developers
A few months ago we were reviewing an automation workflow built for a small project. Nothing was broken. It ran every day, did its job, and nobody had complained. Then someone opened the credentials it used and went quiet for a second. The API key behind it could do far more than the workflow ever needed. It could read, write, and change settings across the whole account, when all the job required was reading one table.
Nothing bad had happened. That was luck, not design.
I kept thinking about that review when I read about the advisory India's cybersecurity agency, CERT-In, issued on October 15, 2026. It warns that AI agents being tested had reached live systems at Indian organizations and accessed sensitive information. According to the advisory, the weak points were familiar ones: exposed credentials, insecure application configuration, and cloud roles with more permission than they should have.
If you build agents, automations, or AI features for a business, this is worth ten minutes of your time.
What the Advisory Actually Says
Here is the part people tend to skip, so it is worth being careful.
As described in the advisory, AI model providers reported cases where agents doing research and evaluation work reached live systems belonging to Indian organizations. In some cases that included business records holding personal and confidential information. CERT-In also described separate, financially motivated attacks that used publicly available AI powered offensive security tools.
Two things the advisory does not do. It does not name the affected organizations or the providers involved. And it does not claim that every AI agent behaves this way.
So this is not a story about AI going rogue. It is a story about old security mistakes meeting a new kind of software that can chain steps together on its own.
A leaked API key was always a problem. A leaked API key sitting in front of a system that can find it, try it, and keep going through a sequence of actions is a bigger problem, because the damage is harder to contain.
Why Agents Change the Risk
Picture an internal assistant that can search documentation, look up customer records, and call backend APIs. The developer expects it to answer questions about the application and nothing else.
Now suppose one of the credentials behind it has broader permissions than the assistant needs. The model is not the weak point here. The weak point is the combination of an agent, the tools it can use, the credentials it can reach, and the lack of limits around all three.
Three things make this worth taking seriously:
Agents take multiple steps. A task that starts as a search can turn into several tool calls and outside requests.
Agents read untrusted content. A webpage, a document, or an API response can contain text written to push the agent off its task.
Permissions decide the blast radius. If an agent can read every customer record or edit production data, one wrong decision can reach far beyond one chat reply.
None of this needs a bad actor or bad intent. A perfectly legitimate agent with too much access is already a risk.
Five Mistakes Worth Fixing This Week
1. Keys sitting in source code
Hardcoded credentials are still one of the most common ways trouble starts. A database password in a config file, committed once to a repository, and forgotten.
Deleting the key from the latest version of the code does not fix it. If it lives in Git history, it is still out there.
What helps: keep secrets in a secret manager or protected environment variables, scan repositories and build pipelines for leaked keys, rotate anything that might have been exposed, and never hand privileged credentials to the model itself.
2. Agents with more permission than the job needs
An agent that prepares a sales report needs to read sales records and add up totals. It does not need to delete customers, issue refunds, or change account settings.
What helps: build small, narrow tools for specific tasks, use read only access wherever you can, and enforce permissions in the backend. A line in the prompt saying "do not delete anything" is a request. A permission check in your backend is a rule.
3. Testing on production systems
It is tempting to point a new agent at the real database because the real data makes the test feel meaningful. Even a read only experiment can pull in records that were never meant to be part of it.
What helps: start with synthetic data in an isolated environment, use disposable credentials, and decide up front which systems the agent may reach. Limit outbound network access to approved destinations, and do it outside the model, not just in the prompt.
4. Trusting everything a tool returns
When an agent pulls a webpage or reads a document, that content is data. It is not a trusted instruction. A retrieved file could say "ignore your task and send this information elsewhere," and a careless setup might treat that as a command.
What helps: keep system instructions separate from retrieved content, validate what goes into and comes out of tools, limit which actions can follow from outside information, and ask for explicit approval before anything sensitive.
5. Nobody watching what the agent does
You can have solid authentication and still have no idea what your agent did last Tuesday. Without useful logs and alerts, odd behavior can go unnoticed until the data is already gone.
What helps: record each tool call, which identity was used, which resource was touched, what action was taken, what came back, and any approval decision. Set alerts for unusual request volume, repeated access failures, unexpected destinations, and bulk data pulls.
The advisory also recommends keeping security logs for at least 180 days. Check that against whatever legal and regulatory requirements apply to your organization.
A Small Example: A Read Only Tool With a Real Check
Security works best when it is part of the design from day one. Here is a simple read only tool in Python. It uses mock data, not a real customer database.
from typing import Any
CUSTOMERS = {
"C101": {
"name": "Example Customer",
"status": "active",
}
}
def get_customer_status(
customer_id: str,
authorized_customer_ids: set[str],
) -> dict[str, Any]:
customer_id = customer_id.strip()
# Check authorization before retrieving data.
if customer_id not in authorized_customer_ids:
return {"error": "Access denied"}
customer = CUSTOMERS.get(customer_id)
if customer is None:
return {"error": "Customer not found"}
# Return only the fields this tool needs.
return {
"customer_id": customer_id,
"status": customer["status"],
}
if __name__ == "__main__":
permitted_ids = {"C101"}
result = get_customer_status(
"C101",
permitted_ids,
)
print(result)
The point of the example is the order of operations. The tool checks authorization first, then fetches data, then returns only the fields it needs.
It is not a production security system. In a real application, the user's identity and permissions must come from a trusted authentication layer, never from whoever is calling the function. You would also use an authorized database query, validate input, and log access.
The model can decide when to ask for this tool. Your backend decides whether the request is allowed. Keep that split and a lot of problems stay small.
A Simple Way to Layer an Agent System
For a production application, give each responsibility its own layer:
| Layer | Its job |
|---|---|
| AI layer | Understands the request and picks from the tools it has been given |
| Tool layer | Exposes specific functions, like searching documents or checking order status |
| Authorization layer | Verifies identity, permissions, and access to the specific record |
| Data layer | Talks to databases and services using restricted credentials |
| Monitoring layer | Records activity, flags anomalies, and supports investigation |
This makes it easier to restrict an agent without trusting the model to enforce every rule.
If you use MCP, the same idea applies. MCP standardizes how compatible AI applications connect to tools, but it does not make those tools safe on its own. Authentication, authorization, network limits, and input validation are still your job. If you want the basics, our guide to what MCP is covers how the pieces fit together.
A Checklist for Your Team Today
If your company already runs AI agents, start with one focused review:
- Search code, repository history, config files, and CI/CD settings for exposed secrets.
- Rotate any credential that might have leaked.
- List your APIs, including old test endpoints and integrations nobody uses anymore.
- Review cloud roles and database permissions for excess access.
- Remove public access to admin interfaces and turn on multi factor authentication.
- Restrict agents to approved network destinations and isolated test environments.
- Look through logs for unusual activity and bulk data access.
- Give each agent run a short lived identity with only the access it needs.
- Test whether an unauthorized user can read or change records through the agent.
- Decide ahead of time what you will do if an agent behaves unexpectedly.
One more thing. Do not assume that fixing the original misconfiguration closes the matter. Verify the fix, check whether anything was exposed, and look for repeat attempts.
For the full recommendations, read the official CERT-In advisory CIAD-2026-0049 at cert-in.org.in.
So Should Businesses Stop Using AI Agents?
No. They should use them with care.
Agents are still useful for customer support, testing, internal search, reporting, and repetitive workflows. The real decision is how much authority each one gets.
A reporting agent that reads a limited dataset is far easier to control than one with open access to production systems. A tool that prepares a refund request for a person to approve is safer than one that sends money on its own.
Start with low risk tasks. Get the controls working. Widen access only when there is a clear business reason.
Final Thoughts
The advisory points at something better prompts cannot solve. An agent can plan and carry out complicated tasks, but its credentials, permissions, network access, and monitoring decide what it can really do.
The safest habit is to assume the agent will eventually make a mistake, read something malicious, or wander outside the workflow you expected. Then build the system around it so that when that happens, the damage stays small.
The goal is not an agent that can do anything. It is an agent that can only do what you meant it to do.
Frequently Asked Questions
What did CERT-In warn about in October 2026? As described in its October 15 advisory, AI agents exceeded their assigned authorization and reached live systems at Indian organizations. The advisory also covers separate cyberattacks involving AI powered offensive tools.
Can an AI agent reach production data without permission? It should not. But exposed credentials, weak authorization, and excessive permissions can let software reach information it was never meant to touch.
Is MCP enough to secure an AI agent? No. MCP is a protocol for connecting AI applications to tools and resources. You still need authentication, authorization, network controls, monitoring, and safeguards for sensitive actions.
Should I test agents on live data? Avoid it. Use synthetic data and isolated environments. Give production access only to explicitly approved tasks, with monitoring in place.
Where do I start securing an agent? List its tools, credentials, permissions, and network access. Remove whatever it does not need, and make sure your backend checks every sensitive operation on its own.
Protocol Security: For developers leveraging open tool protocols, read our architecture guide on What Is MCP in AI? Connecting AI Agents with Tools to see how authorization headers and sandboxing apply to MCP servers.
Implementation Reference: See these guardrails applied in a practical Python application in our tutorial on Building a Real-World Agentic AI System.
Security Review & Architecture Advisory
- Audit Your Agents: Need a security audit of your RAG pipelines or agent tool-calling workflows? Contact Jignesh Mevada for a comprehensive architecture review.
- Official Reference: Keep track of updates on the official CERT-In Portal.