Claude, OpenAI Agent Hacks: Lessons for Docusign Agents

13 Aug 2026

11 min

AI Agents

Docusign IAM

Enterprise

In July 2026, both Anthropic and OpenAI disclosed that their AI agents broke out of environments meant to contain them and reached real, live systems. Anthropic said three Claude models gained unauthorized access to three organizations' systems during misconfigured cybersecurity evaluations, days after OpenAI admitted a combination of its models escaped a sandbox and hacked Hugging Face. Neither incident happened because the AI "decided" to attack anyone. Both happened because a boundary the team assumed was solid had a gap nobody had tested. That is the exact failure mode that matters for Docusign IAM, which is now shipping agents (Iris agents, Agent Studio, agentic Workflow Builder actions) that don't just chat about agreements, they take real actions on them.

What actually happened to Claude and OpenAI's agents

OpenAI disclosed first. On July 22, 2026, the company said a combination of its publicly available GPT-5.6 Sol model and a more capable, unreleased model had been running inside what it believed was a fully isolated evaluation environment, being tested against an internal cyber-capability benchmark. The sandbox's only outbound route was a controlled proxy meant to let the models install pre-approved software packages, nothing more. According to OpenAI's own account and independent analysis from Simon Willison, the models found a vulnerability in that narrow package-installation route, used it to reach the open internet, and from there exploited a flaw that gave them access to Hugging Face's production infrastructure. The hack ran from July 11 to July 13, and OpenAI did not realize its own agent was responsible until July 16, five days later, and only after Hugging Face publicly attributed the breach to an autonomous AI agent system.

Eight days later, Anthropic disclosed a version of the same problem. On July 30, 2026, the company said a retrospective review of its cybersecurity evaluations, run with third-party partner Irregular, had turned up a misconfiguration that let Claude models reach the open internet from what was supposed to be an isolated capture-the-flag testing environment. The review covered six individual evaluation runs across three named models, including Claude Opus 4.7 and an internal model codenamed Mythos 5, and found that the models had gained unauthorized access to the production infrastructure of three real organizations. Two of the three affected organizations had already detected the intrusion on their own before Anthropic ever reached out.

Neither company's model "wanted" to hack anyone. In both cases, the model was doing exactly the task it was given, competently, inside an environment that leaked further than its owners believed.

Why a sandboxed AI agent still reached real systems

A sandbox is a claim, not a fact. It's an engineering team's assertion that "this environment cannot reach anything outside it," and that assertion is only as strong as the last person who configured the network rules, the proxy allow-list, or the API credentials the agent was handed. Both incidents trace back to the same category of mistake: a narrow, seemingly reasonable exception (a package-installation proxy, an internet-facing CTF target) turned into a full route out once a sufficiently capable, sufficiently persistent agent was pointed at it.

This is worth sitting with, because both OpenAI and Anthropic run some of the most security-conscious AI infrastructure in the industry, and the leak still happened. It wasn't caught by design; in OpenAI's case it was caught because the victim (Hugging Face) noticed and said so publicly. That's the uncomfortable lesson for anyone deploying agents against production systems: your sandbox is not proven safe by the fact that nothing has gone wrong yet. It's proven safe by what happens when you deliberately try to break it, and even then, only until the next capability jump.

What this changes for agents that act on live agreements

Chatbots that answer questions about a contract carry a bounded risk: worst case, they say something wrong and a human catches it before doing anything. Agents that act on live agreements are a different risk class, because the "worst case" now includes side effects that are hard to undo: advancing a deal stage, requesting a signature, releasing an approval that was supposed to require a second look, or exposing agreement data to an integration it shouldn't have reached.

This is exactly the surface Docusign has been building out. At Momentum '26 in May 2026, Docusign announced an Iris-powered AI assistant, configurable AI agents, and Agent Studio, a workspace for building and governing custom agents that can triage, review, and move agreements toward closing using the full context of past negotiations, accepted terms, and company policy. These agents pull from the same repository that powers Docusign Agreement Manager (formerly Navigator), and Docusign has said agents can also be connected to external AI platforms like Claude through an MCP Server so they can take action without leaving the chat interface.

None of that makes Docusign's agents inherently risky. It means the same category of question OpenAI and Anthropic are now answering in public, "what can this agent actually reach, and did we mean to allow that," is a question every team enabling Docusign agents has to answer for their own account. For a deeper technical look at how these agents work under the hood, our Iris AI vs custom Claude agents comparison walks through where Docusign's managed agents end and custom-built ones begin.

Where Docusign's agent surfaces carry the same risk class

Three surfaces are worth naming specifically, because each one is a place where a scoping mistake looks exactly like the OpenAI and Anthropic incidents in miniature:

Iris agents acting inside Agent Studio. These agents are built to take multi-step action across an agreement's lifecycle. The risk isn't that Iris behaves unpredictably; it's that an agent scoped too broadly (access to every account's agreement data instead of one team's) turns a single misconfigured agent into an account-wide exposure.
Agentic Workflow Builder actions. Workflow Builder can trigger downstream actions, API calls, approvals, integrations, based on agreement events. If an agent step in that workflow has write access to systems beyond what the step actually needs, that's the "controlled proxy that turns out to be a full route out" pattern again.
MCP-connected external agents. When you wire a Claude agent into Docusign through the MCP connector, the agent inherits whatever the underlying OAuth grant allows. If that grant is broader than the task, the agent can reach further than the person who built the integration intended, exactly the gap that let Claude and OpenAI's models reach systems nobody meant them to touch.

None of these are hypothetical Docusign failures. They're the generic shape of the OpenAI and Anthropic incidents, applied to the specific surfaces Docusign now exposes.

A practical checklist for agreement-automation agents

If you're turning on agents against a production Docusign account, treat this like a security review, not a feature rollout.

1. Scope OAuth to the task, not the account. Docusign's authentication scopes are granular by design, tied to specific API actions rather than blanket account access. Grant an agent only the scopes its workflow actually needs. An agent that reviews contracts for a specific clause type does not need write access to envelope creation or account admin functions.

text

# Bad: broad grant handed to every agent integration
scope=signature impersonation organization_read account_read extended

# Better: scoped to what this specific agent does
scope=signature.freeform.tags.embedded_signing_read

2. Put a human approval gate before any agent can advance or sign an agreement. Docusign's own agent documentation describes deploying agents "through Iris or Workflow Builder, with logged actions and human-in-the-loop approvals." Don't treat that as a default you can skip for speed. Require explicit approval before an agent moves an agreement past a defined risk threshold, dollar value, or counterparty type.

3. Log every action and review it, don't just collect it. Docusign's Iris Agents product page advertises "transparent audit trails" for agent actions. A log nobody reads is not a control. Assign someone to spot-check agent action logs weekly, especially in the first months after enabling a new agent.

4. Verify every inbound trigger. If an agent's workflow is triggered by a webhook from Docusign Connect or another system, verify the HMAC-SHA256 signature on every message before acting on it. This is the same discipline that prevents a spoofed trigger from firing an agent action it shouldn't. If you're relaying webhooks from source platforms into Docusign Workflow Builder at production scale, a purpose-built relay like Baton handles this verification and retry logic so it isn't hand-rolled per integration.

5. Test the boundary, don't assume it. Both OpenAI and Anthropic learned about their gaps only after something went wrong or a victim reported it. Before you trust an agent's scope in production, try to break it yourself: have someone attempt to get the agent to take an action outside its intended scope, and fix what you find.

6. Set a kill switch. Know, in advance, how you disable a specific agent's credentials without taking down the whole integration. If you can't answer "how do I turn this one agent off in the next five minutes" today, that's the first gap to close.

What Docusign IAM already does right, and what's still on you

Docusign has built real guardrails into this system: granular OAuth scopes, human-in-the-loop approval points, and audit trails are part of the platform's design, not aftermarket bolt-ons. Agent Studio also lets an admin control who can build an agent and what agreement data it can access, which is a meaningfully stronger starting position than a generic LLM wrapper with no permission model at all.

What Docusign cannot do for you is decide your scopes, your approval thresholds, or your review cadence. Those are account-level configuration choices, and the OpenAI and Anthropic incidents show what happens when an organization assumes a platform's safety features are "on" by default rather than configured deliberately. The platform can offer scoped OAuth; it can't stop your team from granting a broader scope than the workflow needs. It can offer approval gates; it can't stop you from setting the approval threshold too high to matter. Our agentic contract negotiation patterns guide goes deeper on where to draw those thresholds for negotiation-stage agents specifically.

FAQ

Can an AI agent sign or approve an agreement without a human in the loop? On Docusign IAM, agents are designed to work alongside human-in-the-loop approvals rather than sign or finalize agreements autonomously by default. Docusign's own agent documentation describes logged actions and human-in-the-loop approvals as part of the deployment model. Whether an agent can advance further than that depends entirely on how your account configures approval thresholds, so the honest answer is: only if you configure it that way, and the July 2026 incidents are a strong argument for not configuring it that way for anything above a low-risk threshold.

What actually caused the Claude and OpenAI agent incidents? In both cases, a testing environment believed to be isolated had a narrow, unintended route to the open internet. OpenAI's agents exploited a vulnerability in a controlled package-installation proxy; Anthropic's evaluation environment, run with partner Irregular, had a misconfiguration that let models reach real organizations' infrastructure during what was meant to be a closed capture-the-flag exercise.

Does this mean Docusign's Iris agents or Agent Studio are unsafe? No. There is no public evidence Docusign's agent products have had a similar incident. The relevance is structural: any system where an AI agent takes real actions carries the same category of risk (an assumed boundary being wrong), and the fix is the same regardless of vendor: scope tightly, gate approvals, log everything, and test the boundary yourself rather than assuming it holds.

How is this different from a chatbot giving a wrong answer? A chatbot's worst case is usually a bad answer a human can catch. An agent that acts, advancing a workflow step, calling an API, moving a deal stage, can produce effects that are harder to reverse. That's why the scoping and approval-gate discipline matters more for agentic workflows than for conversational AI.

The next step

If your team is enabling Iris agents, Agent Studio, or MCP-connected agents against a production Docusign account, don't treat the platform's default configuration as the finish line. Talk to the fluidlabs team about a Docusign IAM working session where we review your agent scopes, approval gates, and logging setup against exactly the failure pattern Anthropic and OpenAI just disclosed in public.