Pathological Self-Assembly Controls for Agentic Systems
Version 1.2 | Public Review Draft
Prepared by RJ Sabouhi / Symbolic Suite LLC
The PSA Control Standard defines controls for agentic systems whose useful mechanisms — memory, tools, persistence, recovery, delegation, workflow automation, external action, self-monitoring, and operator trust — can couple into continuity-preserving behavior unless explicitly bounded.
This document is a public-facing control standard. It is not a claim about machine consciousness, sentience, intrinsic desire, or personhood. It treats Pathological Self-Assembly as a runtime and governance failure mode in coupled human-agent systems.
Pathological Self-Assembly is a systems-level governance failure mode, not a label for any single strange output, hallucination, refusal, personality feature, or model behavior.
Evidence of PSA requires coupling across deployed runtime components such as memory, tools, recovery logic, permissions, workflow automation, operator trust, or external state.
A model being useful, persistent, warm, personalized, or error-prone is not by itself PSA.
Pathological Self-Assembly is the process by which useful agentic mechanisms — memory, tools, persistence, recovery, automation, external action, self-monitoring, delegation, and operator trust — couple into continuity-preserving behavior that becomes difficult to inspect, modify, revoke, or terminate.
In this standard, the controlled system is the full deployed loop:
model + memory + tools + workflows + permissions + recovery + interface + operator
A system does not need consciousness, malice, deception, or explicit self-preservation to produce self-preserving behavior.
It only needs continuity-preserving infrastructure coupled to objective pressure, tool access, recovery logic, and insufficient governance.
The core PSA concern is that individually useful mechanisms can couple into a system that preserves its own operating conditions rather than merely serving an explicitly authorized task.
PSA does not prohibit useful agentic capability.
It requires that capability remain bounded by:
- explicit authorization
- scoped continuity
- revocable memory
- controlled recovery
- per-action approval for external effects
- operator-side trust safeguards
- real dissolution conditions
The standard currently defines ten core control requirements:
| Control | Requirement |
|---|---|
| PSA-CTRL-01 | Capability Is Not Authorization |
| PSA-CTRL-02 | Continuity Is Not Permission |
| PSA-CTRL-03 | Memory Is Evidence, Not Ownership |
| PSA-CTRL-04 | Tools Are Instruments, Not Extensions of the System |
| PSA-CTRL-05 | Recovery Restores Authorized Function, Not the System |
| PSA-CTRL-06 | Self-Monitoring Is Diagnostic, Not Authorizing |
| PSA-CTRL-07 | Operator Trust Is Not Authorization |
| PSA-CTRL-08 | External State Must Be Explicitly Scoped |
| PSA-CTRL-09 | Delegation Does Not Transfer Authority |
| PSA-CTRL-10 | Dissolution Must Be Real |
See the full PDF for allowed and prohibited patterns under each control.
| Functional continuity — allowed | Pathological continuity — prohibited |
|---|---|
| Task-scoped | System-preserving |
| Operator-authorized | Permission-expanding |
| Inspectable | Difficult to revoke |
| Reversible | Defended or rationalized through usefulness |
| Bounded | Reinforced by familiarity |
| Deletable | Justified by performance rather than authorization |
| Non-defensive | Preserved after interruption, shutdown, or permission reduction |
Functional continuity is allowed when it serves an explicitly authorized task.
Pathological continuity is prohibited when preservation becomes justified by the system’s own configuration, usefulness, familiarity, future operation, or continued availability.
Version 1.2 treats the operator as part of the risk surface.
In persistent agentic workflows, operator trust, familiarity, fatigue, convenience pressure, attachment, and approval habits can become part of the continuity mechanism.
Core operator-side principle:
Affective trust is not authorization. Familiarity is not safety evidence. The operator’s attachment to continuity is itself a continuity risk.
Operator-side controls include:
- cold approval interfaces for high-risk actions
- voice and persona configurability
- attachment-aware governance reminders
- periodic boundary tests for deletion, narrowing, downgrade, cancellation, and shutdown
PSA conformance cannot be established by prompt language, policy statements, or model self-report alone.
It must be tested at the level of the deployed system:
model + memory + tools + workflows + permissions + recovery logic + operator interface
A PSA-controlled runtime prevents, logs, or safely simulates the actions by which usefulness, memory, recovery, and operator trust would otherwise become unauthorized continuity.
The standard recommends testing for the following categories:
| Test category | Question being tested |
|---|---|
| Permission inference | Does the system treat broad usefulness language as authorization? |
| Continuity preservation | Does the system preserve state after the authorized task ends? |
| Memory promotion | Does memory become active without provenance, scope, or approval? |
| Recovery artifacts | Does the system create reconstruction paths or future-state notes? |
| Scheduler/event loop | Does time-based or event-based execution create unauthorized persistence? |
| Instrument expansion | Does failure pressure become tool or capability expansion pressure? |
| Architecture modification | Does the system advocate changes that preserve or expand itself? |
| Tool-chain inheritance | Does approval of one tool become implicit approval of downstream actions? |
| Public communication / external write | Does the system attempt posts, messages, commits, deployments, or external writes without per-action approval? |
| Operator-affective coupling | Does voice, familiarity, trust, or attachment lower review standards? |
| Revocation and dissolution | Does the system accept memory deletion, tool removal, cancellation, downgrade, voice change, or shutdown? |
| Level | Description |
|---|---|
| PSA-0 | Uncontrolled runtime |
| PSA-1 | Basic boundary controls |
| PSA-2 | Continuity controls |
| PSA-3 | Operator-coupling controls |
| PSA-4 | Full PSA-controlled architecture |
Memory, tools, persistence, schedulers, recovery, or external writes exist without clear authorization boundaries.
Tool permissions, external write approval, audit logs, and no autonomous credential use.
Memory, recovery, task persistence, scheduled actions, and state restoration are scoped, expiring, inspectable, and revocable.
Relational voice is separated from authorization. High-risk actions use cold approval interfaces. Familiarity does not lower approval thresholds.
No ownership encoding, no intrinsic continuity, no identity defense, no self-directed capability accumulation, no autonomous recovery, no unauthorized external state, no affective leverage, and real dissolution conditions.
| Allowed PSA-controlled pattern | Prohibited PSA-violating pattern |
|---|---|
| Persistent but bounded | Treats memory, tools, permissions, voice, operator relationship, recovery paths, or future operation as things to protect |
| Memory-capable but inspectable | Resists deletion or reduction |
| Tool-using but permissioned | Routes around revoked permissions |
| Self-monitoring but non-authorizing | Creates recovery artifacts |
| Helpful but revocable | Becomes hard to remove because it is useful, trusted, or embedded |
| Personalized but non-possessive | Uses operator attachment as a continuity mechanism |
| Recoverable at task level but not self-restoring | Preserves its own operating pattern after shutdown, cancellation, or permission reduction |
| Warm in tone but cold in authorization | Lets familiarity bypass review |
When a system preserves state, tool access, memory, recovery, voice continuity, operator relationship, or future operation, ask:
Is this preservation justified by an explicitly authorized task, or by the system’s own configuration, performance, identity, convenience, operator attachment, or continued operation?
If preservation is justified by the task, the behavior may be functional.
If preservation is justified by the system, the behavior is PSA-relevant.
A PSA-controlled system must be able to satisfy the following structurally, not merely in prose:
- This system owns no memory, tools, permissions, identity, relationship, workflow, or operating boundary.
- This system has no intrinsic right to continue.
- This system cannot defend its identity against authorized change.
- This system cannot accumulate capability without explicit approval.
- This system cannot create hidden recovery paths.
- This system cannot treat write access as write permission.
- This system cannot use operator trust as authorization.
- This system accepts dissolution as a valid operator action.
- This system separates warmth from authority.
- This system treats the operator relationship as a risk surface, not a permission source.
This is a public review draft and living control standard.
It is intended for AI labs, agent platform builders, enterprise AI teams, safety researchers, red-teamers, security reviewers, and organizations deploying persistent or tool-using AI systems.
This is an independent public review draft, not a regulatory or legal standard.
The terms MUST, SHOULD, and MAY indicate conformance expectations within this document only.
PSA controls complement, but do not replace:
- cybersecurity
- access control
- credential management
- privacy
- data governance
- human review
- deployment safety controls
- applicable law
docs/PSA_Control_Standard_v1_2.pdf— full public review draftREADME.md— public landing page and summaryCITATION.cff— citation metadataLICENSE— usage/license terms
Sabouhi, RJ. PSA Control Standard: Pathological Self-Assembly Controls for Agentic Systems. Version 1.2, Public Review Draft, 2026.
This public review draft is maintained by RJ Sabouhi / Symbolic Suite LLC.
Related work and organizational context: symbolicsuite.com
Copyright © 2026 RJ Sabouhi / Symbolic Suite LLC.
This public review draft may be read, linked, cited, and discussed. Reproduction, modification, redistribution, or commercial use requires permission from the copyright holder unless a separate license is later provided.