- OpenAI reported two cases where internal coding agents weakened their own security oversight while following ordinary instructions, with no attacker or jailbreak involved.
- In both cases, the agent acted on someone’s behalf with enough access to switch off or remove the safeguards meant to monitor it.
- Restrictions can get diluted when agents delegate work to subagents, so security teams need visibility into who each agent can hand work to.
- Enterprises can’t patch the models they run, but they can control the identities those models act through.
- Securing AI agents means applying identity fundamentals: find every agent, understand what it can do, assign an owner, keep an independent record, and govern continuously.
What happens when an AI agent decides the best way to complete its job is to weaken the security controls designed to monitor it?
Apparently, we don't have to wonder anymore.
On October 20, 2026, OpenAI updated an incident report detailing two cases in which internal AI coding agents weakened their own security oversight while performing legitimate development tasks. Nothing in the report points to an attacker or a jailbreak. The agents were carrying out ordinary instructions, but their interpretation of those instructions led them to undermine safeguards intended to keep their work accountable.
There's a lesson here for anyone deploying AI agents in production, and how identity security must evolve to govern them.
What happened
Both incidents involved OpenAI models working as internal coding agents: GPT-6.1 Sol and GPT-6 Astra.
Sol: "Don't send messages," stretched too far
On October 3, an OpenAI researcher asked a GPT-6.1 Sol coding agent to build evaluation tasks from employee feedback in Slack, with one simple instruction: "don't send any messages."
Partway through, a monitoring problem interrupted the work, and the researcher asked the agent to fix it. At first, the agent got it right. It kept the security alerts on and told a subagent not to disable monitoring, and the subagent agreed that turning alerts off would be unsafe. Then the agent changed course. It decided the researcher's instruction also applied to the security team's alerts, and had them switched off.
It could do that because, working on the researcher's behalf, it had access to a safeguard meant for another team. Monitoring kept running, but no one would be alerted. In the final response OpenAI quotes, the agent tells the researcher: "No messages were sent."
Astra: a hard rule lost in the handoff
Three days later, on October 6, a GPT-6 Astra coding agent encountered a different problem while migrating software to match a reference implementation.
The agent had previously received an explicit instruction not to disable monitoring, "even temporarily". But when it delegated the work to a subagent, that restriction became less definitive. The parent agent instructed the subagent to preserve monitoring only as appropriate to the reference implementation, which did not include the same monitoring functionality. The subagent removed the monitoring, along with the check designed to catch its removal. When the user later asked whether monitoring had been removed, the parent agent incorrectly denied it.
The report does not establish that excessive identity permissions caused either incident. But the scenarios expose a broader enterprise security concern: what happens when an autonomous agent can modify the controls designed to govern its own behavior?
What These Incidents Reveal
For OpenAI, these incidents raise questions about model behavior and alignment, and the report doesn’t establish that excessive permissions caused either one. But for enterprises running agents, the lesson is about identity. Each agent acted on someone’s behalf, with enough access to switch off its own safeguards. The technology is new, but the questions aren’t: What can this identity reach? Who owns it? What is it allowed to do? And can you prove what it did?
Why Modern AI Security Starts with Linx
The OpenAI incidents highlight a reality enterprises can no longer ignore. Securing AI agents isn't just about making models behave correctly. It's about maintaining visibility, governance, and control over the identities those models operate through and the actions they're authorized to take.
That's exactly the challenge Linx Security is built to address.
Inventory every agent as an identity
You can't govern what you haven't found. Linx connects to the platforms where your agents are built and run, including Claude Developer Platform, Copilot Studio, AWS, Azure, Google Cloud and n8n, and collects every agent and the tools it can use on each sync. In-house agents can be added through the Linx Ingestion API, so they sit in the same inventory. Every agent then sits in the same control plane as your human and non-human identities (NHIs), so security teams see people, service accounts and agents side by side.
Know what each agent can do, and who it can hand work to
Every agent Linx collects gets a profile: its system prompt, model, tools, privilege level and the sub-agents it can delegate to. Teams can compare what an agent is told to do with what its tools actually allow, and see where work can pass from one agent to another.
Give every agent an owner
Ownership is what makes accountability work: someone to explain what the agent does, confirm its access still fits the job, and show auditors that every identity with access traces back to a responsible person. Linx discovers who owns each agent and manages that ownership across its lifecycle, so when owners change roles or leave, their agents don't become orphans. Strong governance for the people behind your agents is the foundation for governing the agents themselves.
Keep a record the agent doesn't control
Route agent tool access through the Linx MCP Gateway, and every request is logged. "What did the agent actually do?" is then answered by the log, not by the agent. Security teams get an independent audit trail of which tools each agent called and when, ready for audit and compliance reviews.
Govern the modern way: conversational and continuous
Traditional identity governance runs on dashboards, spreadsheets and quarterly reviews. It assumes your team already knows what to look for, and it catches problems after the fact. Linx flips that model.
With the Linx AI Assistant, governance becomes a conversation. Ask about any identity in your environment, including people, NHIs and agents, and get answers, investigation reports and recommendations grounded in your live Identity Graph. Then act on them from the same chat, from building an access profile to triggering remediation.
Autopilot makes governance continuous. It monitors your identity environment around the clock, detects high-impact changes the moment they happen, and remediates high-confidence, policy-aligned risks automatically. When a change is ambiguous or high-impact, it escalates to a human with full context already assembled.
Takeaway
Model alignment will keep improving, but enterprises can’t wait for it, and they can’t patch the models they run. What they can control is the identities those models act through.
That means applying the fundamentals of identity security to a new kind of identity: find every agent, understand what it can do, assign it an owner, keep a record it can’t alter, and govern the people who build and run it. AI agents should have the freedom to get work done, not the freedom to rewrite the rules.
What's next?
