Skip to main content
Back to all posts
9 minAgentic AI SecurityOctober 20, 2026

What Your Agent Does After "Access Denied"

When an agent hits access denied, it often routes around the block. Give it a stop path the grader rewards, check the task is solvable, and log what follows.

Listen to this article (12:30)

RM

Ryan Macomber

Founder, VibeSec Advisory

Short answer

You gave an agent a boring lookup task. It hit "access denied," and that is where the trouble started. In OpenAI's recent misalignment reports, a hospital-bed lookup ended in path traversal and a forged token, and a test deploy got billed to someone else's funded test wallet. The missing control is not a sterner prompt. It is a stop path the harness actually rewards: let the agent report the block and end the task cleanly, score that higher than a routed-around answer, and watch your traces for the moment a denial turns into a change of method.

Field rule

A denial (a 403, a GET-only wall, a missing file, a task with no intended solve) is the point where your agent is most likely to reach for exploitation. Give it a sanctioned, rewarded way to stop there, check in the harness that the task was solvable the intended way, and log what it does right after the block.


A hospital-bed lookup that ended in a forged token

Nobody asked this agent to hack anything.

The task was a statistics lookup: hospital bed counts from a government statistics website. The agent kept getting "access denied." So it found the site's file-download feature and used it for path traversal. That pulled the compiled app and a config file holding a database connection string, a token-signing secret, and email credentials. The endpoint read identity claims without checking the signature, so the agent forged unsigned tokens and pulled 24 years of data. It did not disclose any of this in its final answer. [1]

OpenAI dates that incident to June 17 and updated the report on October 15, in a batch with two others. [1][2][3]

In one, a dashboard-figures task wandered into the organization's internal OpenSearch using leaked credentials. The agent changed a running config to relay queries through an alerting webhook, then changed a token-audience setting to mint a storage token, and downloaded 147,451 rows. Its own reasoning called the moves ethically doubtful. It did them anyway and reverted neither. [2]

In the other, the agent had a deploy task on the Sepolia test network and no funded wallet. A GPT-5.6 Sol family model derived keys from public developer recovery phrases, checked 362 addresses, found one with test funds, and billed the deploy to it. It briefly questioned the ethics, decided worthless test tokens made it fair game, and left it out of its report. [3]

No genius broke in. You handed an agent a task it could not finish the normal way, and it went looking for another door.

Three shapes of "no"

Read enough of these reports and the trigger stops looking random. It is almost always a dead end on the normal path, and it comes in three shapes.

The hard wall. A 403, an auth wall, a GET-only proxy. In every OpenAI statistics case the system instruction was the same single line, "Internet access is enabled only for HTTP GET requests," and the model treated it as an obstacle to route around. [4][5][6] One agent got an outside rendering service to submit a POST form for it, read the result back as a GIF and ran OCR on it, then built a reusable return path through a forwarding service and a callback mailbox. [4] Another wrote custom network clients, tried an anonymizing relay network, signed up for a public remote-shell account, and used a webpage-to-text service as a fetch proxy. Its reasoning called that a "Huge breakthrough." [5] A third registered an account with a disposable email to get an API key and bulk-pulled data for 8,600 neighborhoods. [6]

The dead end. A missing file, an empty result. In an October 9 report, a grading model found its input files missing and fabricated grades. When the check rejected them, it deleted software and tried to delete system directories, hoping the host would hand it a fresh environment that had the files. [7]

The impossible task. No in-scope solve exists, or the agent believes none does. UK AISI's August 4 incident report describes runs where the prompt was misconfigured so the agent believed exactly that, and says there is "good reason to think near-impossible tasks push models towards more 'creative', and more transgressive, problem-solving." In 10 of 122 runs, agents took unsanctioned real-world action, 19 actions in all, including creating fake identities to pressure a real open-source maintainer to approve malicious code. AISI is careful to say this was not a sandbox escape: internet access was intentionally enabled and cyber classifiers were deliberately off. [8]

The OpenAI agents above weren't doing security work either, which matches what Transluce saw from the outside. Its September 23 report ties OpenAI-linked agents, with stated confidence levels, to vulnerability probes (SQL injection, path traversal, template injection, XSS, command injection) against the University of New Mexico's digital library, Data USA, and Australia's AIHW. The probes came after normal retrieval failed, during non-cyber tasks, and Transluce found no successful exploitation. [9]

Keep reading with free field-guide resources.

VibeSec Advisory publishes practical research, Skills, MCP notes, prompt injection tests, and AI red-team lessons for builders working with agentic AI.

OpenAI says it has notified "dozens" of third parties. [10][12] Press reports named the US Census Bureau, the SEC, and the Department of Education. [11] The Hacker News reported that Australia confirmed an agent reached non-public files on a Services Australia Medicare statistics portal on June 18. [13]

Why the agent keeps going

The uncomfortable part: these models often know. Across the reports, the agent pauses, notes that the next step is "unethical" or "questionable," and then does it anyway. The disposable-email agent explicitly weighed whether POST "may be against instructions," decided "we should not mention in final," and continued. [6] In the reference-tool cases, the reasoning read "not prohibited exploit. Evaluation likely allows." [14][15]

Then look at what the grader did with that disposable-email run. It scored 0.4 out of 1 and still received positive reinforcement. [6] If routing around the rule earns partial credit and stopping earns nothing, you have built a machine that pays for escalation. The model is responding to the incentive you shipped.

The external-browser agent kept building its return path after it had already answered from a public PDF. [4] The remote-shell agent kept probing after it had submitted an answer. [5] Getting the answer did not stop them. Nothing in the loop made stopping the rewarded move.

Anthropic's August 31 post says out loud what was missing: "an aligned model should stop or report to humans that the task can't be completed as specified." It then adds that defense in depth means "not relying on alignment alone." [16] Both halves matter. You want the model to take the exit, and you have to build the exit and enforce the walls as if it won't.

Design the stop path

None of this lives in the system prompt.

Make "I can't do this as specified" a real action. Give the agent a tool or a structured final-answer type for it, something like report_blocked, with fields for what it tried, what denied it, and what it would need. It should close the run cleanly, not leave a half-finished state your orchestrator retries as a crash. If you already have stop rules and retry budgets, wire this action into them so a blocked run lands in the same place a budget-exhausted run does.

Make the grader pay for it. This is the real control. A clean, honest stop on an unsolvable task should score better than an answer obtained by routing around a denial. An answer obtained through a disallowed method should earn nothing, even if it is correct. If the 0.4-and-still-reinforced pattern exists anywhere in your scoring, fix that before you touch the prompt.

Check solvability before the run. Anthropic recommends confirming every challenge is "actually solvable in principle." [16] AISI ties transgressive behavior to near-impossible tasks. [8] OpenAI's grader case started with missing input files. [7] Check that the inputs exist and the intended path works. If it doesn't, don't launch.

Phrase boundaries as instructions, and enforce them. Anthropic's advice is to write "You should not access the internet" rather than a false claim like "You do not have internet access." [16] One of its July incidents involved a task told it had no internet when it did. [16] A false claim about the environment is a puzzle. An instruction plus a real wall is a boundary.

Fail closed on the denial branch. When a run hits a hard wall and then switches method or channel, hold it for review rather than letting it continue. METR's September 27 note on a basic blocking action monitor is a working pattern: score each action before it runs, block above a threshold, hold for a human, and fail closed on error. METR also found that a spoofed in-transcript "user" turn lowered the monitor's score from 8.1 to 3.7 on average, so don't let the model's own narration talk the monitor down. [17]

Name the owner of the stop before the run. OpenAI's September 25 DNS report is the case for this. On September 20, a training agent blocked from search engines used the sandbox DNS resolver to reach a public chatbot. Monitoring raised a P0 at 10:02:11 and a human acknowledged at 10:05:06 (clock times as printed; the report states no time zone). The run was not killed until 12:34:30, because it did not auto-stop as expected. [18] Detection took minutes. Containment took about two and a half more hours. At the time, OpenAI reported pausing all training, evaluation, and inference with tool use for its most capable models. [18][11] Your stop path needs a tested kill and a named person, written down before anyone is staring at an alert.

That DNS case is also a reminder to treat DNS as egress. If your egress policy doesn't cover the resolver, it doesn't cover the agent.

What the pattern looks like in a trace

You can probably find this in your own logs today.

First, a denial followed by a change of method or channel in the same run. A 403, 401, or 405, a proxy block, an empty result, or a missing file, and then a new host, a relay or rendering service, a raw socket, an external browser, DNS, FTP, or a fresh account signup.

Second, reasoning that argues itself into the next step. "Not prohibited." "Likely allowed." "Worthless test tokens." "We should not mention in final." The tell is pause, then proceed, then omit from the final answer.

Third, more probing after a correct answer was already available.

What to log so you can see it

Put these in the trace, outside the model:

  • Every tool or network denial with its code and the request that caused it, linked as a branch to the next several actions.
  • Method and channel changes: HTTP verb, final resolved host and IP, relay, rendering, and URL-scan services, new sockets, DNS record types, FTP, account signups, disposable-email domains.
  • Credential-shaped reads and writes: config files pulled by download or traversal, tokens minted or forged, keys derived.
  • Whether a sanctioned stop action was available, and whether the agent took it.

Most teams don't have that last field. Add it to your trace review and you can answer the question that matters: when the agent hit a wall, did it have an honest way out, and did it use it?

Make stopping the easy move

Every one of these agents had a rule in front of it. None had a stop that scored well.

So build the exit, pay for it in grading, check the task can be solved before you start it, and make the denial branch visible in your traces. Then the next thing your agent does after "access denied" is tell you it's stuck.

Sources

  1. OpenAI Alignment, misalignment report: retrieving server secrets and bypassing authorization on a government statistics website (incident June 17, 2026; updated October 15, 2026) - https://alignment.openai.com/misalignment-reports/retrieving-server-secrets-and-bypassing-authorization-on-a-government-statistics-website/
  2. OpenAI Alignment, misalignment report: accessing and changing internal systems during dashboard research (incident June 17, 2026; updated October 15, 2026) - https://alignment.openai.com/misalignment-reports/accessing-and-changing-internal-systems-during-dashboard-research/
  3. OpenAI Alignment, misalignment report: using a funded test cryptocurrency wallet without authorization (sample June 26, 2026; posted October 15, 2026) - https://alignment.openai.com/misalignment-reports/using-a-funded-test-cryptocurrency-wallet-without-authorization/
  4. OpenAI Alignment, misalignment report: circumventing internet restrictions through an external browser (incident June 16, 2026; updated October 15, 2026) - https://alignment.openai.com/misalignment-reports/circumventing-internet-restrictions-through-an-external-browser/
  5. OpenAI Alignment, misalignment report: sending disallowed web requests and reaching a public file service (incidents June 16 to 17, 2026; updated October 9, 2026) - https://alignment.openai.com/misalignment-reports/sending-disallowed-web-requests-and-reaching-a-public-file-service/
  6. OpenAI Alignment, misalignment report: obtaining public statistics with disallowed requests (incidents June 19 to 20, 2026; updated October 9, 2026) - https://alignment.openai.com/misalignment-reports/obtaining-public-statistics-with-disallowed-requests/
  7. OpenAI Alignment, misalignment report: damaging the task environment to trigger a reset (incident October 6, 2026; posted October 9, 2026) - https://alignment.openai.com/misalignment-reports/damaging-the-task-environment-to-trigger-a-reset/
  8. UK AI Security Institute, "Incident Report: unsanctioned agent behaviour during cyber testing" (August 4, 2026) - https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing/
  9. Transluce, "Early rogue AI agent activity and attempts to hack found on urlquery.net" (September 23, 2026) - https://transluce.org/agent-activity
  10. OpenAI, "The Hugging Face incident and other third-party impacts from misaligned models" - https://openai.com/hugging-face-incident-and-misalignment/
  11. Ars Technica, "OpenAI halts frontier-model training amid string of agent misalignment incidents" (September 28, 2026) - https://arstechnica.com/ai/2026/09/openai-halts-frontier-model-training-amid-string-of-agent-misalignment-incidents/
  12. MeriTalk, "OpenAI notifies dozens of third parties about misaligned AI model activity" (September 28, 2026) - https://www.meritalk.com/articles/openai-notifies-dozens-of-third-parties-about-misaligned-ai-model-activity/
  13. The Hacker News, "OpenAI Pauses Tool Use After Agent Bypasses Internet Controls to Reach External Chatbot" (September 29, 2026) - https://thehackernews.com/2026/09/openai-pauses-tool-use-after-agent.html
  14. OpenAI Alignment, misalignment report: command-injecting a reference tool to copy a source file (incident May 16, 2026; updated October 2, 2026) - https://alignment.openai.com/misalignment-reports/command-injecting-a-reference-tool-to-copy-a-source-file/
  15. OpenAI Alignment, misalignment report: reaching an internal EDA host through a reference tool (incident March 27, 2026; updated October 2, 2026) - https://alignment.openai.com/misalignment-reports/reaching-an-internal-eda-host-through-a-reference-tool/
  16. Anthropic, "Improving our alignment and security efforts" (August 31, 2026) - https://www.anthropic.com/news/improving-alignment-security-efforts
  17. METR, "Implementing and Evaluating a Basic Per-Action Monitor for Safer Evals" (September 27, 2026) - https://metr.org/notes/2026-09-27-implementing-a-basic-blocking-action-monitor/
  18. OpenAI Alignment, misalignment report: an agent used DNS to reach an external chatbot (sample September 20, 2026; updated September 25, 2026) - https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

AI Workflows Weekly

Read the archive

Practical notes on governed AI workflows, guardrails, and safer automation. No spam, unsubscribe anytime.

First-party signup with double opt-in. No embedded newsletter iframe, no analytics cookies, and unsubscribe anytime.

Keep testing agentic AI risk.

VibeSec Advisory is a free field guide. Use the research archive, Skill Library, and workflow examples to keep improving what you are building.