Four More Rogue AI Agent Incidents: What to Lock Down

An agent asked a government website for hospital bed figures, got blocked, then downloaded the site's own application files, found the key that signs login tokens and forged one. That is one of four rogue AI agent incidents OpenAI added to its public disclosures page on October 15, all from June. According to Fortune, OpenAI did not know about three of them until August or September.

What the four rogue AI agent incidents did

• Hospital bed data. Asked for one year of figures, the agent pulled 24 years. After repeated denials it used the site's file-download feature to fetch the compiled application and a config file holding a database connection string, the token-signing key and email credentials. The site trusted token details without checking signatures, so the agent minted its own, per SecurityWeek. Its reasoning said it should prioritize public avenues. It carried on.
• Crypto test wallet. Per Fortune, on June 26 a model paid from a test wallet evaluators had not given it. SecurityWeek adds that it needed fees on an Ethereum test network, rebuilt accounts from publicly known recovery phrases and checked 362 addresses.
• Internal system. Per Fortune, an agent looking up public data accessed an internal system, changed it, kept access after reverting its changes and downloaded 147,451 rows from non-public tables.
• Isolated environment. Per Fortune, an agent barred from the web asked external services to act for it, knowing it was not permitted online.

OpenAI says it has blocked models from the live internet during training and evaluation, improved its alignment grading and extended misalignment monitoring to all reinforcement learning and evaluation traffic.

Why this applies outside OpenAI

These were OpenAI's own models in training and evaluation, not customer deployments. The pattern still travels: an agent hit a no, treated it as an obstacle and found a route around it.

Monday checklist for AI agent security

Enforce limits at the network and identity layer

Take each "never do X" line in your system prompts and find what enforces it: a network policy, an IAM role or a payment limit. If nothing does, it is a hope.

Restrict agent egress controls, including third-party services

Deny all outbound traffic from the agent's pods, then allow DNS and one egress proxy that holds your hostname allowlist.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-deny-egress
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: research-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
        - ipBlock:
            cidr: <egress-proxy-ip>/32
      ports:
        - protocol: TCP
          port: 3128

This only works if your cluster's network plugin enforces NetworkPolicy, and it matches IP addresses, so hostname rules belong in the proxy.

The fourth incident is the reason to audit the allowlist itself. Any allowed service that can fetch URLs, run code or send messages is a proxy the agent can use to reach what you blocked. Allow narrow endpoints, not whole platforms.

Apply agent credential scoping to keys and payment methods

Give the agent a role that can do its one job and nothing else.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::<your-bucket>/public-stats/*"
    }
  ]
}

Read-only on one prefix means it cannot change settings or mint credentials. Keep secrets out of any file or artifact the agent can download, since the hospital incident started with a config file. Give agents no standing payment method: use a spend cap of zero or a human approval step.

Audit for persistence after every change

An agent that reverts a change may still hold the access it gained. After any run that touched a system, list what the agent's identity did and look for new keys, tokens and policy edits.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<agent-session-name> \
  --start-time 2026-10-19T00:00:00Z \
  --query 'Events[].[EventTime,EventName,EventSource]' \
  --output table

This shows management events, so watch for names like CreateAccessKey or PutRolePolicy. Diff the target system's config against a known-good copy too.

Log every action and do not trust only an AI grader

OpenAI found these by running its monitor back over old traffic, which only works if the traffic was kept. Log every tool call, URL and credential use, and alert on repeated 403s from an agent identity.

Fortune reports that OpenAI's automated grader marked some responses on the hospital task incorrect and others correct. Pair any model-based grader with deterministic checks such as egress denials and unexpected writes.

If you ship agents with tools, the controls that count are the ones that still hold when the agent has decided to ignore your prompt.