Loading workgroup…
Workgroup
Developing containment strategies and technical measures to prevent AI systems from exceeding intended boundaries or causing unintended consequences.
A peek at recent conversation in DP13 - AI Containment. Join to read the full history and post.
Join workgroup →Ron Petty sent these notes on DP13 by email:
I read through DP 13; it's a very nice start. I need to let it soak in and read it again. Only immediate issue is Section 4, Core Principle. It seems "containment" is the core principle, but the section doesn't open directly with it. It's extra important to make this clearer because Section 5 starts with it.
The last couple of bullets on 5 might need review:
- Containment tiers for new entrants - could be clearer for external agents (sounds like internal)
- Symmetry across capability and influence - not sure if same machinery is valid in all cases (aka my macbook with some gpu can enforce X and Y, but in reality Y is not possible on that configuration -- so machinery becomes more of a "logical" term than "implementation")
Intro on 6, might use words "internal" and "external" as those where used earlier (just to tie back).
- 6.1 talks about high-risk but unclear where that gets defined/enforced (maybe just reference to prior section)
- 6.3 it was mentioned earlier that scale wasn't only way to influence but that is all that is talked about here
- 6.4 talks about sandboxes, but doesn't define -- don't forget original computers are designed to be multi-user friendly (aka the ultimate sandbox between advanced agents aka humans)
- 6.6 what tooling does community use to reach consensus and where is the kill switch since sandboxes reduce insight
I think 15 really sums up what are the engineering / ops concerns
Daveed's reply to Ron Petty, sent by email:
Hi Ron,
Thanks for reading it closely enough to catch that Section 4 never actually says 'containment' before it states the principle. Your section-by-section notes were easy to act on, and the line about 'machinery' being a logical term rather than an implementation is exactly right.
I turned your notes into seven proposals, credited to you:
In DP13, replacing the sentence "Every AI actor operates within explicit, machine-enforced boundaries over scope,…", I've proposed: "The core principle of DP13 is containment. Every AI actor operates within explicit, machine-enforced boundaries over scope, time, rate, data, tools, and influence, with observable state and rapid shutdown, unless a community-defined policy (DP12) specifies otherwise."
In DP13, replacing the sentence "Unknown agents, plugins, and integrations begin in a restricted tier…", I've proposed: "Unknown agents, plugins, and integrations begin in a restricted tier and earn capability through observed behavior, attestation, and governance review. This applies to external agents as well as internal ones: an agent arriving from outside a zone starts with restricted interaction rights, such as no unsolicited contact and low rate limits, until it earns more in that zone."
In DP13, replacing the sentence "The same machinery that limits what an agent can execute…", I've proposed: "The same logical controls that limit what an agent can execute also limit how it can act upon attention, emotion, and belief. Implementations differ by deployment; where an environment can enforce a capability limit but not an influence limit, that gap is disclosed rather than assumed away."
In DP13, replacing the sentence "While capability containment is critical for agents deployed by users…", I've proposed: "Capability containment is critical for internal agents, those a user or community deploys. Influence containment matters most for external agents, those acting upon participants, which are the dominant risk in open environments because they shape perception, behavior, and collective reality."
In DP13, replacing the sentence "Default posture is deny-by-default for high-risk capabilities and high-risk interaction…", I've proposed: "Default posture is deny-by-default for high-risk capabilities and high-risk interaction patterns. What counts as high-risk is set by community policy for each zone, context, and risk class (Section 9, DP12) and enforced at the execution boundary (Section 5)."
In DP13, below the sentence "This applies especially to external agents attempting to influence at…", I've proposed: "Rate limits address volume, but influence does not depend on scale alone. A single persistent agent, a well-targeted message, or a slow drift in tone can shape belief without exceeding any rate cap. Those patterns are handled by incentive and influence boundaries (Sections 6.8 and 6.9) and by detection (Section 15)."
In DP13, below the sentence "Execution occurs in isolated environments with no ambient access to…", I've proposed: "A sandbox is an execution context with its own identity, permissions, and resource limits, separated from other agents and from its host, much as a multi-user operating system separates its users. Access to files, network, credentials, or other agents is granted explicitly, never inherited. Kill switches and logging sit outside the sandbox at the enforcement boundary, so isolation does not stop anyone from seeing or stopping what the agent does."
Each will show up in the chapter's discussion once it's posted, and you can comment on or refine it there. For the sandbox one, check that I've represented your multi-user point the way you meant it.
What I didn't turn into text: your 6.6 question about the tooling a community uses to agree on pulling a kill switch. Section 15 says zone-level pause authority and scope are set in advance, but how a community reaches that decision is a DP12 governance question. I'll take it to the workgroup rather than invent an answer. The 'where is the kill switch' half went into the sandbox proposal. Glad Section 15 reads as the ops summary to you.
You mentioned a second pass. Anything you send by early November can still make V1.
With thanks,
Daveed
Diane Strahan sent these notes on DP13 by email:
I am not sure I have access to the full chapter on AI Containment because when I clicked into it a number of times it appears that it's just about four screens deep so if that is the case, I have read the entire chapter. […]
One question I have is in regard to the first paragraph: is there a reason we cannot add "what an agent may NOT do."
This addresses parents containment of AI for their children, but what happens when they don't --which we have to assume at least 50% of the time parents won't know how to or have time to because they're busy working. So this empowers parents to have the ability to contain agents for their children, it does not address those children, whose parents do not contain the agents ---where then does the responsibility lie? Today, parents are being held responsible for not locking up their guns and their kids then taking them and shooting people. Is there a repercussion if parents don't have any oversight or responsibility of AI agents who their children set up purposefully for bad actor behaviors? Should children be able to set up agents, which can exhibit bad behaviors without parental oversight?
I didn't necessarily understand who could revoke the scope of an agent. Only the developer/ creator? Or are certain community members or industry experts allowed to identify problematic behaviors and submit those for review? Is there an automated community agent that is identifying bad behaviors as exceptions to have them looked at by other AI agents protecting the community or by humans?
Daveed's reply to Diane Strahan, sent by email:
Hi Diane,
Thank you. Your question about children whose parents never set anything up is exactly the case the chapter needs to handle and doesn't yet. The comparison to locking up guns makes the stakes plain.
First, about the chapter: you were right to suspect you hadn't seen all of it, and that was our problem, not yours. DP13 is one long page with 17 numbered sections, from '1. Purpose of This Draft' to '17. Closing Orientation', and the reader didn't make that clear. On a phone or tablet, the discussion panel could also cover the chapter, so it looked only a few screens long. We've changed the reader since your email: the chapter now stays in view, with a Discuss button to open the conversation, and the links below take you straight to the passage each proposal is about. Your other questions are partly answered further down: Section 9 covers who can pause and revoke, and Section 15 covers detection.
I turned your notes into four proposals, credited to you:
In DP13, below the sentence "These constraints limit scope, tools, data access, rate, and persistence…", I've proposed: "Containment states what an agent may not do as clearly as what it may do. A participant should be able to see the actions an agent is barred from, not only the permissions it holds."
In DP13, below the sentence "Similarly, external agents may be restricted from initiating certain categories…", I've proposed: "Protection for children cannot depend on every parent setting it up. Where agents may interact with minors, protective defaults apply automatically at the zone and platform level, whether or not a parent has configured anything. An agent set up by a minor begins in the most restricted tier for its zone and still maps to an accountable party (DP1)."
In DP13, below the sentence "DP13 therefore requires that containment state and containment failures surface…", I've proposed: "Revoking or narrowing an agent's scope is not reserved to its developer. A participant can restrict an agent within their own context, community governance can restrict it within a zone, and the deploying party can restrict it wherever it operates."
In DP13, below the sentence "anomaly detection on rate, chaining depth, budget consumption, and outreach…", I've proposed: "reports from participants, community members, and domain experts, which enter the same incident queue as automated detection; automated monitors can throttle or quarantine pending review, while lasting revocation goes through accountable human review"
Each will show up in the chapter's discussion once it's posted, and you can comment on or refine it there.
To your direct questions. Who can revoke an agent's scope? Not only the developer. Section 9 says participants can pause, revoke or restrict agents acting on them, and communities can quarantine whole classes of agents. Section 11 explicitly disallows shutdown paths that only operators or model providers can reach. The third proposal just says this plainly. Can community members and automated monitors flag problems for review? Section 9 already calls for reports with a traceable response and incident queues; the fourth proposal makes clear that both kinds of signal feed the same review.
What I didn't propose: whether parents should face repercussions, and whether children should be allowed to set up agents at all. Those are legal and policy calls the workgroup should make, not me, so I'll bring both to the DP13 group.
The seat in the workgroup is still yours if you want it, and once you've had a chance to scroll through the whole chapter, any further notes are welcome.
With thanks,
Daveed
A correction from Daveed on the DP13 comment from Paul Werbos relayed here on October 14:
The "Comment on DP13 (AI Containment)" is a joint piece by Paul Werbos and DeepSeek Qi. It was introduced here as "drafted with DeepSeek Qi and sent under his name". Please read and credit it as their joint work.
Community Chats match workgroup Collab: human messages in the main panel and private Deepi in the right sidebar. Invite people outside the workgroup by email or link. This is separate from Workgroup Chat, which stays inside the member thread.
Start a Community Chat for DP13 - AI Containment. You pick who joins. Everyone invited can post in the member chat and use private Deepi in the sidebar. The chat appears in your Deepi sidebar with a Community badge.
Sign in to start a Community Chat from Deepi.
Opens Deepi with the invite flow. Community Chats also appear under My conversations at /agent.