The threat model extends beyond prompt injection
A serious Agent will ingest web pages, email, documents, tool results, retrieved Memory, messages from other agents, and model-generated Artifacts. It will operate over long periods, delegate recursively, compose several Capabilities, and act in environments whose state changes independently. The relevant question is therefore broader than whether the model can distinguish trusted instructions from hostile text:
If a cognitive Resource is confused, compromised, overconfident, or strategically manipulated, what semantic changes and real-world effects can it cause? Prompt injection remains an evolving form of social engineering. OpenAI's published work emphasizes layered controls, monitoring, and limiting consequences even when manipulation succeeds.[1]Current agent systems and engineering evidencesourceOpen bibliography entry →[2]Current agent systems and engineering evidencesourceOpen bibliography entry → Persistent Semantic Agency treats the same problem at the architectural level: the model is allowed to reason and propose, while the system independently governs meaning, Authority, and effect.
Content carries influence, not automatic Authority
An external Source may provide data, a claim, Evidence, or an Artifact without gaining the right to instruct the Agent. Useful influence classes include:
AUTHORIZED_INSTRUCTION
POLICY
TRUSTED_DATA
UNTRUSTED_DATA
EVIDENCE
TOOL_RESULT
EXTERNAL_MESSAGE
A web page, email, retrieved Memory, document, tool output, or another model's message does not become an instruction because it appears inside a trusted ContextPack, sits near system text, or resembles a command.
Instruction Authority comes from explicit Principal, Policy, and Responsibility semantics, not from textual position. This distinction is more precise than a binary trusted/untrusted label. A calendar provider may be authoritative for the existence of an event and have no Authority over travel Policy. A repository may be authoritative for current code while strings inside the repository remain untrusted content for behavioral control. Trust must therefore be scoped by claim type, purpose, integrity, freshness, and Source Authority.
Influence lineage makes risk inspectable
A proposal may depend materially on externally supplied or untrusted content without being automatically invalid. The system should preserve that influence lineage so that Policy can ask whether an effect requires independent Verification, human review, stronger Evidence, or a reversible execution path.
Is the proposal materially influenced by untrusted content?
Which claim or Decision depends on it?
Is the proposed effect reversible?
Does Policy require independent review?
This lets the system use the web, email, and documents as sources of information without granting those sources a hidden path to Authority.
Reasoners produce proposals
Models, humans, Plugins, and DomainCompilers generally produce a ProposedSemanticChange rather than mutating arbitrary canonical state.
Resource output
→ ProposedSemanticChange
→ schema validation
→ Authority and purpose check
→ Policy and Trust check
→ support and Context validation
→ revision and conflict check
→ admission or rejection
The boundary does not make bad reasoning harmless. It makes the blast radius explicit, attributable, and enforceable outside the Resource that produced the result. A rejected proposal remains useful provenance; it does not become accepted Work merely because the model was persuasive.
Effects stay bound to delegated purpose
Every consequential effect must remain justified by the Responsibility and Commitment that created its legitimate purpose.
Effect
must be justified by
ResponsibilityAssignment
within
Commitment and Principal Authority lineage
An executor may not reuse valid credentials or technically available Capabilities for an unrelated objective. This Intent Binding also prevents a hostile document from manufacturing a new purpose: the document may alter an assessment or create a Contradiction, but it cannot create legitimate Authority.
Authorization is compositional
Per-call permission is too weak for long-horizon systems because individually permitted actions may compose into a prohibited outcome.
read private file individually allowed
send email individually allowed
send private file contents externally
not implied
Authorization may therefore consider the current action, prior effects in scope, accumulated spend, delegated purpose, information flow, Risk, irreversibility, and redelegation history. This is compositional, history-sensitive Authority, not ordinary tool allow-listing. Macaroons establish an important precedent through decentralized authorization, contextual caveats, and attenuation.[3]Capability security and authorizationsourceOpen bibliography entry → Emerging work on task-scoped authorization and transitive authorization propagation for agents addresses the need to bind permissions to task lineage.[4]Capability security and authorizationsourceOpen bibliography entry →[5]Capability security and authorizationsourceOpen bibliography entry → The proposal here integrates that security logic with Commitment, Responsibility, Context, Evidence, and Closure.
A usable implementation must also avoid the opposite failure, which I call authority lockup: the long-horizon-agent analogue of label creep or over-tainting in information-flow systems. Decentralized IFC and declassification research already show that useful systems need explicit principals and controlled release conditions, while purpose-based access control binds data use to intended purposes and prohibitions.[6]Capability security and authorizationsourceOpen bibliography entry →[7]Capability security and authorizationsourceOpen bibliography entry →[8]Capability security and authorizationsourceOpen bibliography entry → Empirical IFC work documents loss of permissiveness and label creep under aggressive tracking, and recent LLM and agent systems explore influence-sensitive propagation, isolated branches, registered sanitizers, call-scoped rulings, and controlled declassification outside the model.[9]Capability security and authorizationsourceOpen bibliography entry →[10]Capability security and authorizationsourceOpen bibliography entry →[11]Capability security and authorizationsourceOpen bibliography entry →[12]Capability security and authorizationsourceOpen bibliography entry → In this architecture, a viable Policy model should keep influence lineage scoped by purpose, data class, effect domain, Responsibility, provenance, and validity interval rather than treating any contact with sensitive Context as permanent global contamination. Those dimensions are a design proposal, not a complete calculus. Sanitization, declassification, or lineage attenuation remain explicit governed transitions under Policy and appropriate Authority; where their correctness is not mechanically established, they also require admissible Evidence or independent review. The formal language and algorithms that balance under-enforcement against over-tainting remain open.
Constraints must remain live state
The final research pass found close precedents for structural security rather than prompt-level guardrails. Constraint State Governance argues that safety-critical constraints must remain explicit execution state as they move through Memory, Delegation, communication, tool use, audit, and optimization; it names the loss or weakening of those constraints constraint drift.[13]Capability security and authorizationsourceOpen bibliography entry → AgentKernel proposes a mandatory and non-bypassable operating-system substrate organized around identity, perception, cognition, and execution, with input mediation, information-flow-controlled Memory, and semantic-to-kernel enforcement below orchestration frameworks.[14]Capability security and authorizationsourceOpen bibliography entry → These are stronger precedents than application-level filtering. Persistent Semantic Agency does not claim to invent explicit constraint state or trust-native kernel enforcement. It extends them into a wider constitution in which constraints remain linked to Principal, Commitment, Responsibility, purpose, compositional Authority, Evidence, Acceptance, and Closure.
Authority must still be valid when an effect becomes durable
A long-running computation may begin under a valid Policy snapshot and finish after the relevant Authority, Facts, verifier, model version, or task state changed. Successful computation is therefore insufficient to authorize a durable consequence. Temporary Authority, Permanent Effects defines commit-time authorization: the witness licensing a durable effect must remain fresh, causally prior, bound to that effect, and eligible when the consequence becomes durable.[15]Capability security and authorizationsourceOpen bibliography entry → Authority at Commit Time treats agents as proposal producers and a logically authoritative service as effect authority; it compares declared dependencies and producing components with current state, applies the current verifier, and rejects only affected stale work for resynchronization and rerun.[16]Capability security and authorizationsourceOpen bibliography entry →
reasoning or Execution completed
≠ effect authorized
proposal + dependency manifest + current Authority
+ current verifier + idempotent effect reservation
→ admitted durable effect
The architecture proposed here generalizes the same law beyond one effect service. Admission remains scoped and federated, but no consequential mutation becomes legitimate merely because the Resource finished computing it.
Delegation cannot widen Authority
Recursive Delegation obeys one mandatory invariant:
Authority(child) ⊆ Authority(parent)
The same narrowing applies to data, credentials, Capabilities, budget, purpose, time, region, and redelegation power. A delegate cannot manufacture permission; a lower-scope ConfigurationProfile cannot widen a higher-authority restriction; a learned Procedure cannot modify an AuthorityGrant. Attenuation is what lets a system delegate aggressively without converting every descendant into an ambiently privileged agent.
Capability contracts describe consequences
A Capability is more than a callable function or input schema. Its contract describes input and output, operation and effect class, scope and Authority requirements, credential needs, Risk, reversibility, idempotency, transaction behavior, Evidence produced, Observation semantics, and failure or retry classes. Useful effect classes include:
PURE_COMPUTE
READ_OBSERVATION
INTERNAL_STATE_MUTATION
REVERSIBLE_EXTERNAL_EFFECT
IRREVERSIBLE_EXTERNAL_EFFECT
FINANCIAL_EFFECT
COMMUNICATION_EFFECT
PHYSICAL_EFFECT
Effect class influences approval, Delegation, isolation, Verification, reconciliation, and rollback. A Capability being technically present says nothing about whether it is authorized for the current Responsibility.
Credentials are resolved at the execution boundary
Reusable secrets should never become ordinary model Context. The semantic system carries an opaque CredentialBindingRef; a broker resolves it only after evaluating the Principal, accepted ResponsibilityAssignment, purpose, Capability, current AuthorityEnvelope, Policy, and effect history.
Principal
+ ResponsibilityAssignment
+ purpose
+ Capability
+ current AuthorityEnvelope
+ Policy and effect history
→ scoped credential use
A model can request an authorized effect without receiving the reusable key that would allow unrelated effects. The rule applies to API keys, OAuth tokens, cloud credentials, SSH keys, passwords, and financial credentials.
Observation and action are separate Capabilities
Sensors read repository state, inbox, calendar, CI, monitoring, financial feeds, browser state, or physical sensors. Effectors modify code, send communication, create events, deploy, publish, purchase, or move funds. Read access does not imply mutation. An executor's report does not replace an independent sensor. Separating the two also supports safer execution patterns in which a model proposes an effect, a governed component performs it, and another component observes the result.
Ambiguous effects require reconciliation
External systems sometimes return uncertain outcomes. A payment request may time out after the payment occurred, leaving neither clean success nor clean failure as an honest state.
AMBIGUOUS_EFFECT
→ reconciliation Work
→ authoritative Observation
→ retry, compensate, or continue
Blind retry is unsafe when the effect is non-idempotent or externally irreversible. The system first recovers actual state, then chooses the next transition.
Data access follows purpose
A delegate receives the minimum sufficient data for its Responsibility. Principal, privacy, purpose, scope, sensitivity, allowed consumer, region, retention, and exposure constraints operate before semantic relevance ranking. A travel-booking Resource may receive itinerary constraints, travel preferences, loyalty status, budget, and required identity fields. It should not receive unrelated health Memory, source-code Context, or complete financial history. High embedding similarity cannot override a forbidden purpose or wrong Principal.
Independence is also a security property
Verification is weaker when it reuses the producer's model, Source, Context, rationale, and execution environment. The system may therefore require independence across model family, Source lineage, organization, Context exposure, data origin, or environment. A security reviewer can receive the Artifact, Obligations, and authoritative inputs while being denied the producer's persuasive reasoning. The goal is not ignorance; it is to prevent one compromised or mistaken cognitive path from validating itself.
Plugins and Skills enter through a supply-chain boundary
A Plugin may contribute executable code, schemas, Procedures, external connections, Source-Authority rules, verifiers, or Closure rules. Installation therefore requires explicit identity, integrity, TrustClass, compatibility, and isolation semantics.
CORE
BUILT_IN
VERIFIED
ORGANIZATION
USER
UNTRUSTED
Trust determines what a contribution may register or execute. It does not grant Authority to act on Work.
installed ≠ active ≠ applicable ≠ authorized ≠ selected
Historical objects remain bound to the extension and schema revisions that defined them. An upgrade cannot silently reinterpret past Authority, Evidence, or Execution.
Long-horizon systems require ongoing governance
One-shot safety evaluation misses risks that emerge across a trajectory: gradual Authority misuse, stale assumptions, cumulative side effects, and changes in the world after an earlier approval. OpenAI's long-horizon safety work explicitly highlights trajectory-level monitoring together with intervention and rollback requirements.[17]Current agent systems and engineering evidencesourceOpen bibliography entry → The architecture therefore preserves effect history, trajectory-level provenance, ongoing Observation, Authority revocation, reconsideration, rollback or compensation where possible, and human visibility. A persistent Agent must remain governable after its first approval.
Autonomy belongs to the Responsibility
There is no global autonomous mode.
web Research autonomous
produce draft autonomous
send communication Policy-dependent
production deployment approval-dependent
sign legal contract human Authority
large financial transfer human Authority
The correct boundary depends on Authority, Risk, reversibility, confidence, Evidence, Policy, cost, and effect class. The same Agent may be fully autonomous for Research and unable to send the resulting email without approval.
Human silence is explicit waiting
Silence does not grant consent unless an authorized Policy explicitly defines that behavior for the specific Responsibility and Risk level. Waiting for human input is a first-class semantic state with a response, deadline, event, or Policy trigger. The system can remain dormant without repeatedly asking a model whether silence should now be interpreted as approval.
Security is structural when compromise remains bounded
Assume hostile content manipulates a model. The model's output is still a proposal. A consequential effect must pass purpose binding, Authority and Delegation attenuation, compositional effect history, Policy and privacy, Capability contract, credential isolation, Context and data scope, effect admission, independent Observation, and Verification. This does not make compromise impossible. It changes the failure mode from “the model had a tool, therefore the attacker gained the tool” to a bounded, observable, and policy-mediated attempt.
Security invariants
- Content never acquires instruction Authority through retrieval, quotation, or tool delivery.
- Capability availability never grants Authority.
- Delegation can only narrow Authority.
- Consequential effects remain bound to purpose and Responsibility lineage.
- Credentials are resolved at the execution boundary.
- Authorization may consider composed history, not only one call.
- External effects are independently observed.
- Ambiguous effects require reconciliation.
- Plugins cannot weaken Core laws through installation.
- Learning cannot expand Authority.
- Personal data remains Principal- and purpose-scoped.
- Historical Authority and Evidence remain interpretable after upgrades.
The security thesis
A safe Agent is not a perfectly obedient model. It is a system in which no model, document, tool result, Memory item, Plugin, or delegate can silently acquire semantic Authority beyond its admitted role, and in which consequential effects remain bounded, observable, attributable, and revisable.