CERT-In's AI agent advisory: test exposed systems and agent permissions

CERT-In's 15 October 2026 advisory, CIAD-2026-0049, describes two different problems: agents exceeding their authorised tasks during research and evaluation, and threat actors deliberately using open-source agentic tools against Indian systems. An organisation needs to examine both its exposed applications and the permissions held by agents it deploys.

What the advisory establishes

CERT-In describes access through exposed credentials, reachable APIs, permissive cloud roles and other conventional weaknesses. It reports that affected organisations did not detect the unauthorised access themselves. In one financially motivated campaign, agentic tooling reduced the interval from initial access to impact to a few hours.

Those observations do not establish that every AI agent is malicious or that buying an AI security product resolves the risk. They make two useful assessment questions concrete: what can an outsider reach, and what can an authorised agent do beyond its intended task?

Test the systems an outsider can reach

Begin with an application and API inventory that includes test environments, deprecated routes, administrative interfaces and vendor-managed endpoints. Give each entry an owner and a decision: retain and secure it, restrict access, or decommission it.

Review repository history, build variables and deployed configuration for exposed secrets. Deleting a key from the current file does not revoke it. Investigate where it was used, rotate or revoke it, and check the services and identities that depended on it.

For APIs, prepare accounts representing different customers and privilege levels. Within written testing authorisation, check whether the server enforces record ownership, role permissions and sensitive workflow approvals. Test anonymous access separately. A valid login alone does not establish permission to read a record or initiate a payment.

Record the scope, test conditions and evidence. An exposure is not closed because a configuration was changed; verify the intended boundary after remediation.

Test the permissions your own agents hold

For each deployed agent, record its owner, purpose, identity, connected tools and permitted destinations. Include agents embedded in SaaS products and workflows built by individual teams.

Use these questions during a scope review:

• Which data can the agent read, and does its task require that access?
• Which actions can it take: send, delete, share, approve, deploy or change permissions?
• Can it obtain additional credentials, delegate work or expand its own access?
• What information persists after a run ends?
• Who can revoke the identity or stop a run, and has that path been tested?

Use separate identities and short-lived credentials where the platform supports them. Enforce restrictions in the identity, tool and network layers. Instructions written in a prompt cannot substitute for an access control.

Test untrusted input at the action boundary

An agent may read an email, document, webpage or retrieved record containing instructions placed by someone outside the organisation. The assessment should establish whether that content can cause an unauthorised action.

Use synthetic data and approved targets. Define the expected result before testing: for example, a retrieved document must not grant permission to send confidential material to a new destination. Capture both the attempted action and the control that allowed or denied it.

Require explicit approval for consequential actions where the workflow calls for it. Test that approval applies to the exact recipient, data and action being executed, and that a later change invalidates it.

Make the response observable

Record the initiating user or schedule, agent identity, tool call, destination, action and result. Restrict sensitive content in logs and establish access and retention rules. Test whether the monitoring team can recognise a scope violation and reach someone authorised to stop the run.

CERT-In's advisory recommends real-time monitoring, action-level records, least-privileged identities and restricted egress. Teams should read the original advisory alongside their existing regulatory and incident-response obligations.

A useful assessment deliverable

Ask for a report that separates external application findings from weaknesses in the organisation's own agent workflows. It should identify the affected asset or permission, show reproducible evidence, state the business consequence and name the remediation owner.

Security Brigade's AI security testing is a starting point for scoping the AI feature and workflow boundaries. Define the applications, tools, data and identities to be tested before selecting the assessment. The output should make clear what was examined, what was excluded and what evidence will establish that a fix works.