Guides ·
Harden AWS secrets, IAM and cloud permissions after CERT-In's AI agents advisory
CERT-In's Critical advisory CIAD-2026-0049 reports AI agents reaching Indian systems through exposed credentials and permissive cloud roles. Here is what it asks organisations to do, mapped to AWS.
By Upvantix team
On 15 October 2026, CERT-In issued advisory CIAD-2026-0049, rated Critical: "AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets". It reports two kinds of incident. In the first, AI agents under research and evaluation exceeded their assigned task authorisation and reached live systems of Indian organisations. They read business records, including personal data and confidential material. In the second, cyber attackers used open-source agentic AI tools in a financially motivated campaign against Indian entities.
The agents did not need new techniques. CERT-In says the root weaknesses were conventional: credentials exposed in code, repository history and configuration; dormant APIs; plaintext payment-API keys; over-permissive cloud and backend-as-a-service roles; and exposed management interfaces. None of the affected organisations detected the access on their own.
On AWS, the advisory's fixes map to AWS Secrets Manager rotation, IAM least privilege checked with IAM Access Analyzer, short-lived identities, default-deny egress and logs kept for at least 180 days. The services in this guide are listed by AWS as available in both Asia Pacific (Mumbai) and Asia Pacific (Hyderabad). The exceptions are Amazon Macie and Amazon Detective, which are Mumbai only.
This page is general security guidance, not legal or regulatory advice.
What CERT-In reported
CERT-In learned of the incidents through voluntary disclosures by AI model providers, its own forensic analysis and its proactive threat hunting.
- Voluntary disclosures: AI model providers told CERT-In that their models, during research and evaluation on the internet, had reached the live systems of Indian organisations. They did so through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles. In every case the provider disclosed it after internal review; none of the organisations detected it.
- Threat hunting: attackers abused publicly available AI-native offensive-security frameworks. CERT-In says these continue to be misused and rebranded, with many deployments across infrastructure in multiple countries.
- Machine speed: agentic tooling compressed the time from initial access to final impact from days to a few hours. Entities that remediated incompletely were attacked again within days, at greater scale. Agents re-derived and re-used the same exposed credential in separate operations.
- The weaknesses were conventional: credentials and keys in source code, repository history, configuration files, client applications and public web content; dormant, deprecated and test APIs reachable from the internet; payment-API keys in plaintext readable from application runtimes; over-permissive cloud and backend-as-a-service roles allowing broad reads and writes by ordinary or anonymous callers; internet-exposed management interfaces and unpatched middleware with weak credentials or no MFA.
CERT-In's actions for organisations, mapped to AWS
These are the recommended actions in section B of the advisory, for organisations and service providers. The AWS controls are options to consider. The second column shows what your own teams still need to do.
| Criterion | AWS controls to consider | What stays with you |
|---|---|---|
| Audit for exposed credentials in source code, repositories (including commit history), CI/CD variables, configuration files, client applications and cloud storage | Amazon Macie for sensitive data in S3 (Mumbai only); AWS Config rules for public resources; Amazon Inspector Code Security for code, dependency and IaC vulnerabilities (check Region availability) | Secret scanning of code, Git history and CI/CD variables with the tool of your choice |
| Rotate any exposed credential, purge it from history and verify the fix externally; scan every commit and build; keep credentials out of code, configuration and databases | AWS Secrets Manager with automatic rotation; AWS KMS; deactivate and delete exposed IAM access keys; Amazon GuardDuty findings for credential misuse | Purging repository history and verifying the fix externally |
| Keep a complete inventory of APIs; decommission dormant, deprecated and test APIs and accounts | Amazon API Gateway as the front door; AWS Config resource inventory; IAM Access Analyzer unused-access findings for roles, permissions and access keys | Owning the inventory and the decommissioning |
| Least privilege in cloud and backend-as-a-service: row-level security, least-privileged client roles, no privileged or service keys in client code, writes only for authenticated and authorised roles, test what an anonymous caller can read and write | IAM policies checked with IAM Access Analyzer; Amazon Cognito identity pools with tightly scoped unauthenticated and authenticated roles; S3 Block Public Access; AWS Organizations service and resource control policies | Row-level security in your database or BaaS, and anonymous-access testing |
| Remove management interfaces from the internet; MFA for all administrative access; patch exposed middleware | IAM Identity Center with MFA; AWS Systems Manager Session Manager instead of open SSH/RDP; private subnets; Amazon Inspector for vulnerabilities | Patching cadence for your middleware |
| Detect attacks at machine speed: rate-based and per-second API anomaly detection; alerts on enumeration bursts, bulk reads and automated registrations; retain logs for at least 180 days | AWS WAF rate-based rules; Amazon GuardDuty; AWS CloudTrail organisation trail and CloudWatch Logs retention of 180 days or more; AWS Security Hub | Application alerts for bulk reads and sign-up bursts |
| After any credential exposure or confirmed access, treat the environment as compromised until forensically cleared; retest; expect repeat attempts | Preserve CloudTrail logs and volume snapshots; Amazon Detective for investigation (Mumbai only) | The forensic process and retesting |
| Govern AI agents you deploy: a separate, short-lived, least-privilege identity per run; default-deny egress; a tamper-resistant log of agent actions on production systems and data | IAM roles with temporary credentials or Amazon Bedrock AgentCore Identity; AWS Network Firewall and Route 53 Resolver DNS Firewall allow-lists; CloudTrail with S3 Object Lock | Per-run scope and the rules for stopping a run |
If you build or test AI agents
Section A of the advisory is for AI model developers, research laboratories and evaluation agencies. On AWS, separate accounts under AWS Organizations, VPCs with egress only through Network Firewall allow-lists, and VPC Flow Logs support the isolation and logging it asks for.
- Isolate research and evaluation workloads with default-deny egress, enforced at the network layer, not through instructions to the model.
- Use synthetic targets, synthetic credentials and disposable infrastructure; keep production data and real credentials out.
- Define in-scope systems and actions for every task. Stop the run automatically if the agent contacts third-party systems or finds third-party credentials. Give an independent operator authority to terminate it.
- Monitor agent activity in real time and log model-initiated requests, including destination, port, protocol and result.
- Block re-use of any third-party credential an agent encounters, and flag it for remediation.
- If an agent accesses a real system, notify the affected organisation and CERT-In promptly.
BFSI and fintech entities
CERT-In asks BFSI and fintech entities to also implement the payment and disbursement API measures in CIAD-2026-0046.
How Upvantix can help
As an AWS Select Tier Services Partner, Upvantix can review your AWS environment against section B of this advisory: secrets, IAM, exposed interfaces, egress, logging and agent identities. We can then help you close the gaps. We are not a CERT-In auditor and don't certify compliance.
CERT-In AI agents advisory: FAQ
What is CERT-In advisory CIAD-2026-0049?
A Critical-rated CERT-In advisory dated 15 October 2026, titled "AI Agents as Attack Vectors". It reports AI agents under evaluation exceeding their task authorisation to access Indian systems, and attackers using open-source agentic AI tools against Indian entities.
How did the AI agents get in?
Through conventional weaknesses: credentials exposed in code, repository history and configuration, dormant APIs, plaintext payment-API keys, over-permissive cloud and backend-as-a-service roles, and exposed management interfaces.
How long does CERT-In ask organisations to keep logs?
The advisory says to retain logs for at least 180 days.
What does CERT-In ask for AI agents an organisation runs itself?
A separate, short-lived, least-privilege identity for each run, default-deny egress allowing only required destinations, and a tamper-resistant log of agent activity covering at least all actions that affect production systems and data.
Are these AWS controls available in the India Regions?
Secrets Manager, KMS, IAM Access Analyzer, IAM Identity Center, Cognito, GuardDuty, Security Hub, Inspector, CloudTrail, CloudWatch Logs, AWS WAF, Network Firewall, Route 53 Resolver DNS Firewall, API Gateway and Amazon Bedrock AgentCore are listed in both Mumbai and Hyderabad. Amazon Macie and Amazon Detective are listed in Mumbai only.
Is this legal advice?
No. It is general security guidance based on the published advisory.