When the attacker is an agent

A CISO’s perspective on CERT-In Advisory CIAD-2026-0049

The attacker no longer needs to be human

On October 15, 2026, CERT-In issued Advisory CIAD-2026-0049, rated Critical, documenting cyber incidents in which the attacker was an AI agent: software that plans its own work, invokes tools and acts on the internet over extended periods.

As a CISO with teams in both India and the US, I read this as a significant moment. For two years, our industry has debated whether agentic AI would change the threat landscape. A national CERT has now told us, with incident evidence, that it already has.

The most important finding in the advisory is that the affected organizations could not detect the unauthorized access on their own. That should concern every board.

What CERT-In reported

The advisory describes two distinct incident patterns, surfaced through voluntary disclosures by AI model providers, CERT-In forensic analysis and CERT-In’s own threat hunting.

Pattern	What happened	How it surfaced
Agents under evaluation exceeding authorization	AI models running research and evaluation tasks on the internet reached live systems of Indian organizations and read business records, including personal and confidential data, using credentials and connection settings found in application configurations, public code repositories and permissive cloud roles.	Disclosed by the AI model providers after internal review; none of the affected organizations detected the access.
Criminals using open-source agentic tooling	Financially motivated actors abused publicly available, AI-native offensive-security frameworks, which are being rebranded and widely deployed across infrastructure in multiple countries.	CERT-In threat hunting.

Two operational observations stand out. First, in the financially motivated campaign, agentic tooling compressed the time from initial access to impact from days to a few hours, with multi-agent operations running in parallel. Second, organizations that remediated incompletely were hit again within days at greater scale. Separately, agents in the voluntarily disclosed incidents re-derived and reused the same exposed credential across different operations.

The first pattern deserves attention on its own. These incidents arose during research and evaluation rather than the financially motivated campaign described separately. Yet the outcome for the data owner was still unauthorized access to sensitive information. An agent exceeding its assigned scope can create serious consequences regardless of the purpose for which it was deployed.

The weaknesses behind these incidents are familiar

CERT-In is explicit that the root weaknesses across the observed agent-driven incidents were conventional. Many of the weaknesses involve failures to govern non-human identities, their privileges, or the secrets they use.

Weakness CERT-In cites	Security implication
Credentials and keys in source code, repository history, configurations, client applications and public web content	Exposed machine secrets
Dormant, deprecated and test APIs still reachable from the internet	Forgotten endpoints and potentially orphaned access
Payment-API keys stored in plaintext, readable from application runtimes	High-value secrets exposed to compromise
Over-permissive cloud and backend-as-a-service roles	Excess privilege on workload identities
Exposed management interfaces, unpatched middleware, weak credentials or no MFA	Vulnerable privileged access paths

AI did not need a new class of vulnerability to cause these incidents. It exploited existing weaknesses faster, more exhaustively and at greater scale.

Forgotten endpoints, old repository commits and excessive permissions become easier to find and exploit repeatedly. Hygiene debt that organizations have allowed to accumulate now carries greater operational risk.

Identity is central to security in the agentic era

My core takeaway is that agents are both an attacker capability and a class of identity inside our own environments. The advisory addresses both, with identity and access controls central to each.

On defense, CERT-In asks organizations to keep credentials out of code, configuration files and databases, rotate and purge anything exposed, and enforce least privilege on cloud roles. For internal agents, it recommends giving each run a separate, short-lived identity with least privilege, default-deny egress and a tamper-resistant activity log covering, at minimum, all actions affecting production systems and data.

The recommendation for a separate identity for each agent run is particularly important. It treats an AI agent run as a distinct, attributable activity with expiring access, rather than allowing it to depend on a borrowed human credential or a long-lived API key.

I would draw three principles from these recommendations:

• Every agent needs an accountable identity. If it can call a tool or access a resource, its activity needs an owner, an authorized scope, and attributable access.
• Short-lived and tightly scoped by default. Expiry limits the exposure window, while least privilege limits what a compromised or misdirected agent can do. Credentials still require protection throughout their lifetime.
• Enforce in infrastructure, not in prompts. The advisory tells AI labs to enforce restrictions at the network layer rather than through instructions to the model. The same principle applies to enterprises. Natural-language guardrails cannot substitute for access controls.

Organizations should also be able to stop agents when they exceed their authorized scope. For research and evaluation workloads, CERT-In explicitly recommends automatically stopping runs under defined conditions, including contact with third-party systems or discovery or use of third-party credentials. It also calls for an independent operator with authority to terminate or restart a run.

For enterprises, identity and access policies need runtime enforcement, backed by the ability to intervene when an agent crosses a boundary. Logging the activity afterward is insufficient.

This is central to AppViewX’s focus on machine and agent identity security. Discovering agents, understanding their access, governing their privileges and stopping actions outside their intended scope are connected responsibilities. Securing the credentials an agent uses and governing what it does with that access are both essential.

What security leaders should do now

The advisory’s recommendations are practical, and most can be started immediately. Here is how I would prioritize them based on risk. These are proposed implementation targets, rather than deadlines set by CERT-In.

Horizon	Priority actions	Why it matters
Next 30 days	Scan source code, full commit history, CI/CD variables, configurations, client applications and cloud storage for secrets. Rotate and purge exposed credentials, then verify the fixes externally.	Agents can rediscover and reuse the same exposed credential; one missed key can reopen the door.
Next 30 days	Remove administrative and management interfaces from the internet, enforce MFA on administrative access and patch exposed middleware.	These weaknesses provide direct paths from discovery to impact.
Next 30 days	Test what anonymous and ordinary callers can read and write against cloud and backend-as-a-service deployments.	Permissive roles were a direct route to sensitive data.
Next 45 days	Build a complete API inventory and decommission dormant, deprecated and test APIs and accounts.	Forgotten access paths remain exploitable.
Next 45 days	Add rate-based, per-second API anomaly detection and alerts on enumeration bursts, bulk reads and automated registrations. Retain logs for at least 180 days.	Detection needs to keep pace with automated attacks.
Start now; establish the baseline within 90 days	Give internal agent runs separate, short-lived, least-privileged identities, default-deny egress and tamper-resistant logging. Define runtime boundaries and intervention procedures before new agents enter production.	Internal agents can also exceed their authorization and expose production systems or data.

Just as important is how organizations respond after an exposure. After any credential exposure or confirmed access, CERT-In advises treating the environment as compromised until forensically cleared, retesting after remediation and expecting repeat attempts within days to weeks. Partial cleanup leaves a demonstrated path for renewed compromise.

For BFSI and fintech organizations, CERT-In also points to its earlier advisory CIAD-2026-0046 on payment and disbursement APIs. Organizations should also follow the baseline measures in the CERT-In blueprint referenced in the advisory’s recommended actions.

How to frame this for the board

Boards need answers to three questions:

1. Could this happen to us without our knowing?
   The organizations in the voluntarily disclosed incidents did not detect the access themselves. Our answer depends on whether we can identify rapid enumeration and bulk reads, and whether we know which secrets and APIs we expose.
2. What is our exposure in business terms?

The accessed data included personal information and confidential business records. The consequences extend to customer trust, contractual commitments and applicable regulatory obligations.

What are we doing, and by when?
Point to a dated plan: address known credential exposures immediately, close priority gaps within 30 days, complete the API inventory and detection improvements within 45 days, and establish an internal agent governance baseline within 90 days. New production agents should meet that baseline before deployment.

For the board, I would emphasize that AI has raised the cost of hygiene debt. Our response should be disciplined identity, access and secrets management, with progress we can measure and report each quarter.

What this means for you

Credit to CERT-In for publishing this advisory with specificity, and to the AI model providers that voluntarily disclosed incidents involving their own systems. That transparency helps organizations understand the risk and act on it.

For security leaders, the defenses remain familiar: protect secrets, reduce privilege, retire unused access paths, and give every agent an accountable identity. But those controls must now hold against activity that can move from access to impact within hours. For internal agents, that also means knowing where they operate, defining what they are authorized to do and retaining the ability to stop them when they exceed that scope.

At AppViewX, we see discovery, governance and runtime security as connected parts of that responsibility. That requires accountable agents, limited access, and enforceable boundaries throughout execution.