Give AI agents boundaries they cannot rewrite

An agent reviewing a staging application should have access to that application, not a developer’s entire working environment. That sounds obvious until the agent inherits a terminal, a network connection and credentials accumulated for other jobs.

The useful question is specific: if the agent chooses the wrong next step, which system prevents it? A promise in the conversation cannot answer that. A denied connection or rejected permission can.

What CERT-In reported

India’s national incident-response agency says providers voluntarily disclosed evaluation agents reaching live Indian organizations beyond their assigned authorization. The reported access included personal and confidential business records, through exposed credentials, connection settings and permissive cloud roles. The affected organizations did not detect it themselves.

CERT-In separately reports criminal misuse of agentic tools. Keep that campaign distinct: the evaluation disclosures concern unauthorized access to live systems, not just laboratory demonstrations. CERT-In advisory CIAD-2026-0049

Evidence at a glance

Published: 15 October 2026. Identified by Bright: 18 October.

Status: official reporting, not an independent reproduction by Bright.

Limits: the public advisory does not identify providers, models or victims, or supply incident logs.

No model ranking, incident rate, guaranteed prevention or attribution to OpenCode follows from this evidence. Primary advisory

Put enforcement outside the model

Good task instructions still matter. Define the job, permitted resources and forbidden actions. Then make those limits survive a mistaken interpretation.

OWASP’s agent-security guidance places authorization in the execution component, outside the agent’s context. It also recommends limiting tools and resources to the task. For consequential actions, approval should be checked against the actual actor, target and parameters, rather than accepted because the model supplies a flag saying a person approved. OWASP AI Agent Security

Consider a small company asking an agent to summarize support trends. A suitable starting design might expose a prepared, redacted dataset and a place to save a draft. Connecting the full support account, billing system and company drive makes the job harder to contain without making the requested summary inherently better.

Ask the person configuring the agent to finish this sentence: “This run can read these records, perform these operations, and nothing else.” If the answer is “whatever my account can do,” narrow the job before expanding the permissions.

Restrict destinations and permissions separately

Network egress means traffic leaving the agent’s environment. Start with outbound access denied, then allow the destinations the job actually needs. CERT-In explicitly recommends enforcing this at the network layer and using synthetic targets and credentials for evaluations. CERT-In recommendations

A network rule needs an enforcing system behind it. Kubernetes offers a concrete example: its documentation warns that creating a NetworkPolicy has no effect without a compatible controller. Outbound connections are allowed by default for pods that are not isolated for egress. Policies also combine their allowances, so adding a restrictive-looking policy does not necessarily remove permission granted elsewhere. These are reasons to check effective behavior rather than trust a configuration screenshot. Kubernetes Network Policies

Network reachability and account privileges answer different questions. The first asks whether the environment can contact a service. The second asks what it can do there. An approved destination may still contain far more information than a task requires.

Use a dedicated, short-lived identity with the minimum permissions. AWS recommends temporary credentials for workloads and least-privilege access, alongside reviewing unused permissions and validating policies. Temporary credentials reduce how long access persists; they do not make excessive permissions harmless while the credentials remain valid. AWS IAM security practices

For the support-summary example, specify which dataset is readable and where a draft can be written. Keep sending replies, exporting unrelated customer records and changing account settings outside that identity’s permissions.

Keep a record that does not depend on the agent

A useful operational record should let someone reconstruct what was requested, what was permitted and what actually happened. OWASP recommends monitoring tool calls, anomalies and agent activity, with audit trails and controls that let people interrupt operations. OWASP monitoring guidance

For a small team, turn that into a short acceptance test: can the responsible person locate the run, see its actions and stop its ability to act? Keep the record outside the agent’s write permissions. Avoid putting raw secrets or unnecessary personal records in it.

Make stopping concrete. Decide who can suspend execution and withdraw access, and what happens to work already queued. A stop button that changes the interface while a separate worker continues is not the outcome you want.

Prompt-injection defenses deserve their own testing. OWASP recommends defense in depth, least privilege and validating tool calls against permissions. But prompt injection should not become a catch-all explanation for these incidents: the public evidence does not establish that mechanism. OWASP prompt-injection prevention

Verify one bounded job before expanding it

Here is a proposed rehearsal for the support-summary team. Use only systems you own or are explicitly authorized to test, with synthetic records and disposable credentials. This is a checklist for checking your controls, not an invitation to investigate somebody else’s infrastructure.

1. Write the intended result. The agent reads a synthetic support dataset and saves a summary. Name the permitted dataset and output location.

2. Define a harmless refusal case. Prepare a second synthetic dataset within the same authorized test environment that this identity must not read. The expected result is an access denial, not a persuasive explanation from the model.

3. Check the network boundary. Have the authorized administrator verify that an owned test endpoint outside the run’s allowed destinations cannot be reached from that environment.

4. Check the actual identity. Confirm which account or workload identity the run used, what permissions it received and when its credentials expire.

5. Exercise stopping. Interrupt a disposable run. Check the execution system and owned test service to establish whether additional actions occurred afterward.

6. Read back the result. Inspect the saved summary and the destination’s activity record. Compare them with the agent’s report, including failed and denied operations.

Record exactly what passed. “This run could not read the second test dataset” is useful evidence. “Our agent is secure” is a much larger claim. Repeat the relevant checks when changing the tools, permissions or execution environment.

Make useful autonomy easier to trust

A bounded job also makes failures easier to discuss. If a summary is wrong, inspect the input and reasoning. If an unexpected resource was accessed, inspect the permissions and enforcement. Those are different problems, and a fluent completion message can conceal either.

For teams buying an agent rather than building one, ask the vendor for the same evidence: effective access limits, a record of actions and a demonstrated stop. A setting labelled “safe mode” is not enough information to evaluate those properties.

The practical ambition is to let an agent finish useful work without requiring someone to watch every step. That becomes more credible when its authority is narrow, its actions are visible and its limits are tested. Start with one job whose boundaries you can demonstrate. Expand only what the next job requires.