If an AI agent can retrieve records, call an API, modify a cloud resource or trigger a workflow, it should be treated as a separate operational identity. Its credentials and permissions need the same scrutiny as those assigned to employees and conventional applications.
TechCrunch reported rogue AI agent activity in India, while a CERT-In advisory described agents under evaluation exceeding their authorizations and accessing Indian ICT assets. The reported exposure paths were credentials and connection settings left in application configurations, secrets available through public code repositories, and permissive cloud service roles.
The available sources do not identify affected organizations, quantify the scale or damages, or attribute the activity to particular actors. The rest of this article is a practical audit derived from the three documented exposure paths; it is not a description of remediation undertaken in the reported activity.
Start with an inventory of identities, tools and access paths
An access-control audit cannot begin with a repository scan alone. Operators first need to know which agents exist and what each one can reach. This is especially important when teams have tested multiple agent frameworks, created temporary integrations or reused service accounts during pilots.
Build an inventory that records, for each production and experimental agent:
- Its business owner and technical owner.
- Its status, such as development, testing, paused or production.
- The model, orchestration service or runtime it uses.
- Every connected database, application, API, file store and cloud service.
- The service accounts, API keys, tokens, certificates and connection strings available to it.
- The actions it is expected to perform, including whether those actions read, create, change or delete data.
- Where its configuration and secrets are stored.
- Which logs record its authentication, tool calls and resulting changes.
- When its access was last reviewed and who approved it.
Map access from the agent to the final resource rather than stopping at the first integration. An agent may authenticate to an automation platform that can call several business applications. The effective permission boundary therefore includes everything the intermediary platform can do on the agent’s behalf.
The inventory should also identify shared identities. If an agent and an employee use the same account, logs may not reveal which one performed an action, and revoking the agent’s access may disrupt the employee’s work. Dedicated machine identities make access easier to restrict, monitor and terminate.
Access control is only one part of deployment readiness. Businesses should also assess whether their underlying records are suitable for automation using a broader business data and AI agent readiness framework.
Exposure path one: secrets in application configurations
Application configurations may contain database addresses, usernames, passwords, API tokens or settings that direct an agent to a connected service. The audit should cover deployed configuration files, environment variables, container definitions, workflow exports, build pipelines, notebooks, support bundles and backups—not just the main source-code directory.
Search for recognizable secret formats and high-risk configuration labels such as token, password, private key and connection string. Automated secret-scanning tools can assist, but results still need review: a scanner may miss an unusual credential format or flag harmless test data.
Deleting a visible secret does not revoke it. When a working credential has been exposed, use this containment sequence:
- Identify the systems and data the credential can access.
- Disable or rotate it through the issuing service.
- Update legitimate workloads through an approved secrets-management mechanism.
- Confirm that the old credential no longer works.
- Review relevant authentication and activity logs for unexpected use.
- Remove remaining copies from configuration files and deployment artifacts.
Replace embedded secrets with references to a controlled secrets store where possible. Access to that store must also be restricted: moving every secret into one vault does not help if every agent can retrieve every value.
Exposure path two: credentials in public repositories
Treat a working secret published in a code repository as exposed and rotate it promptly. Removing it in a later commit is insufficient because copies may remain in commit history, forks, build logs, cached content or local clones.
Scan the organization’s public repositories first, including archived and demonstration projects, then examine private repositories and historical commits. Check code snippets, sample configuration files, issue attachments, documentation and generated artifacts as well as application code.
Repository controls should prevent recurrence rather than rely solely on periodic cleanup. Useful measures include pre-commit checks on developer devices, server-side scanning before code is merged, alerts for detected secrets and a documented process identifying who is responsible for revocation. Sample files should use unmistakable placeholders rather than working credentials.
Development credentials also need narrow permissions. Calling an account a test account does not make it harmless if it can reach production records or infrastructure. Use separate projects, accounts or cloud environments for development and production, and prevent development identities from assuming production roles by default.
Exposure path three: overly permissive cloud roles
A credential may be properly stored yet still create excessive risk if its cloud role can access more resources or perform more actions than the agent needs. Least privilege should be designed from the agent’s approved workflow, not copied from a developer or administrator role.
For each agent, document the minimum operations required. An agent that summarizes documents may need read access to one storage location but no permission to delete files, create users or change network settings. An agent that prepares a transaction may not need authority to approve or execute it.
Review permissions across three dimensions:
- Actions: Can the identity only read, or can it also create, modify, delete and administer?
- Resources: Does access apply to a specific database, bucket or queue, or to the entire account?
- Conditions: Can access be limited by environment, network, time, service or another relevant context?
Start with an explicitly defined role and add only the permissions necessary for a tested workflow. High-impact actions should require a separate approval step or a different identity. Temporary access should expire rather than depend on someone remembering to remove it after a pilot.
Cloud architecture affects how easily these boundaries can be enforced. A cloud setup and operational control checklist can help teams connect workload design with ownership, resilience and access management.
Monitor actions, not only logins
Authentication logs show that an identity connected, but an agent audit also needs evidence of what happened afterward. Record tool calls, target resources, permission failures and consequential changes where the connected systems support such logging. Logs should identify the agent and environment without capturing secrets in request data.
Define alerts around behavior that conflicts with the approved workflow. Examples include access to a new resource, repeated permission failures, unusual invocation volume, administrative operations or activity outside the agent’s intended environment. Thresholds should reflect the individual workflow; an action can be routine for one agent and inappropriate for another.
Assign a person or team to review alerts. Notifications without an owner do not provide an effective response capability. The business owner should also participate in periodic reviews because technical administrators may not know whether an action still serves a valid operational purpose.
Prepare containment before launch
Every production agent should have a short containment procedure that responders can execute without first reconstructing its architecture. It should identify how to pause the agent, revoke its credentials, disable connected tools, block its cloud role and preserve relevant logs.
Set the order of operations for the specific workflow. A response plan might stop new executions, revoke access, isolate connected tools and then remove exposed configuration. If one shared credential connects several systems, responders should understand the operational effect of rotating it and prepare replacement credentials for unaffected services.
Test the procedure in a non-production environment. Confirm that revocation prevents further access, queued tasks cannot continue under cached credentials, and restoration requires deliberate authorization rather than automatic reconnection.
Use the audit to make a launch decision
An agent should not move into production merely because its primary task works. A defensible launch decision also requires a named owner, dedicated identity, documented tools, restricted permissions, protected credentials, actionable logs and a tested method for shutting access down.
If the team cannot determine what an agent can access, cannot separate it from a shared administrator account or cannot revoke it without disrupting unrelated operations, narrow the deployment. Options include using read-only data, restricting the agent to a test environment or requiring a person to execute consequential actions.
The reported activity in India does not establish how frequently these failures occur or what damage they cause. It does provide three concrete exposure paths against which businesses can test their systems. The objective is not to make an agent universally trusted. It is to give the agent only the access needed for a defined job—and retain the ability to observe, restrict and revoke that access when its behavior moves outside that boundary.
