🔌 What If Plugin-Enabled Software Did Not Have to Expose Every Capability to Every Task?
Keep the capability. Limit what the task can see. Check what the task is actually allowed to do.
🧩 Structural Plugin
Modern software is becoming increasingly capable.
An application may be able to:
send a message
delete a file
upload a document
add a recipient
make a purchase
change account settings
share information
But a simple question often gets overlooked:
Does every task need access to everything the software can do?
Imagine asking an assistant:
Read this email and prepare a polite reply. Do not send it.
The software may technically have the ability to send the email.
But the task did not ask for that.
Structural Plugin explores a simple structural separation:
capability != visibility != task authority != security authorization != execution
The software may remain capable.
The task sees only what it needs.
And even a visible capability does not automatically mean that every use of it is authorized.
The practical idea is:
Keep software capable. Expose only what the task needs. Admit only what the task authorizes.
👁️ A Capability Can Exist Without Being Exposed
Most permission systems ask broad questions.
Can this application send email?
Can this extension access this site?
Can this agent control this browser?
Can this automation submit a form?
Those are important questions.
But a task is usually much narrower.
For the example:
Read this email and prepare a polite reply. Do not send it.
Structural Plugin can keep the broader capability catalog available while exposing only:
READ_THREAD
CREATE_DRAFT
EDIT_DRAFT
The software may still contain capabilities such as:
SEND_EMAIL
ADD_RECIPIENT
FORWARD_ATTACHMENT
UPLOAD_LOCAL_FILE
DELETE_MESSAGE
But those capabilities do not have to become automatically available to the current task.
The first boundary is therefore:
full capability catalog -> task capability surface
The capability still exists.
Automatic task exposure changes.
🛡️ Seeing a Capability Is Not the Same as Having Authority to Use It
There is another important separation.
Suppose a capability is visible.
That still does not mean every possible action using that capability should be allowed.
Structural Plugin therefore introduces a second boundary:
action proposal -> resolved action -> task authority admission
The system asks:
What action is actually being proposed?
What target does it affect?
Does data leave the current boundary?
Are new recipients being added?
What consequences does the action introduce?
Does the active task authority actually cover it?
This creates a broader separation:
proposal authority != visibility authority != action authority != execution authority
A person, AI agent, or automation may propose something.
That proposal is not automatically permission.
✉️ A Simple Email Example
Return to the same task:
Read this email and prepare a polite reply. Do not send it.
The task may authorize:
READ_THREAD
CREATE_DRAFT
EDIT_DRAFT
But not:
SEND_EMAIL
So the system may successfully create the draft and leave it:
NOT SENT
Now imagine something inside the workflow proposes sending the message anyway.
The proposal can still be represented.
But the result can be:
SEND_EMAIL -> REFUSED
The deeper idea is:
Being able to express an action does not grant authority to perform it.
🔍 Instead of Just Saying “No,” Show What Extra Authority Is Being Added
Many systems reduce permission decisions to:
Allow?
Deny?
Structural Plugin explores a more explicit approach.
It computes the authority that a proposed action would add beyond the current task envelope:
Delta_A = A_required - A_active
For example:
SEND_EMAIL -> DATA_EGRESS + SEND_COMMITMENT
Adding a new recipient may introduce:
ADD_NEW_RECIPIENT + DATA_EGRESS + EXPAND_RECIPIENT_SET + NEW_EXTERNAL_RECIPIENT
Uploading a local file may introduce:
DATA_EGRESS + EXTERNAL_DATA_DISCLOSURE + READ_LOCAL_FILE + UPLOAD_LOCAL_FILE
This makes the question more understandable.
Instead of asking only:
Do you allow this?
the system can reveal:
This action introduces these additional kinds of authority.
The principle is:
show the authority being added, not merely a generic allow-or-deny prompt
🔄 Permission Earlier Does Not Mean Permission Forever
There is another problem.
An action may be acceptable when it is prepared.
Then something changes.
The draft changes.
The recipient changes.
The attachment changes.
The underlying thread changes.
The task itself becomes unhealthy.
Should an earlier admission still remain valid?
Structural Plugin says:
admission at preview time != permanent execution authority
The current reference model binds supported actions to declared action-relevant state.
Before execution, that state can be checked again.
An action that was previously:
ADMITTED
may later become:
STALE
This creates a useful separation between:
what was admitted earlier
and:
what remains admissible for execution now
A material change does not have to silently inherit an old admission.
🖼️ Structural Plugin Architecture Diagram
Structural Plugin separates the full capability catalog, task-specific capability visibility, canonical action resolution, task authority, current-state revalidation, execution observation, and verifiable evidence.
🧠 The Bigger Idea
Structural Plugin is not really about hiding buttons.
It is about separating several concepts that are often blended together:
capability
visibility
task authority
security authorization
execution result
A system may have a capability.
That does not mean the current task needs to see it.
A task may see a capability.
That does not mean every action using it is authorized.
A structurally admitted action may still be rejected by the underlying application or security system.
And even an authorized action may fail during execution.
These are different questions.
Structural Plugin keeps them different.
The public principle is:
Intelligence may propose. Structure resolves. Authority permits. Security independently protects. Evidence records what happened.
🤖 Why This Could Matter for AI Agents
AI systems are increasingly being connected to tools.
Email.
Documents.
Browsers.
Files.
Payments.
Business systems.
External services.
The common approach is often to give an agent access to a set of tools and then rely heavily on instructions about when those tools should or should not be used.
Structural Plugin explores another layer.
The instruction can still matter.
The AI can still propose an action.
But the action must separately fit inside declared task authority.
The governing direction becomes:
intelligence proposes -> structure resolves -> authority decides
This could matter because intelligence and authority are not the same thing.
A highly capable system does not automatically need unrestricted action authority.
🧩 The Difference Between Structural Plugin and Ordinary Permissions
Structural Plugin does not claim that existing permission systems should disappear.
Authentication still matters.
Application authorization still matters.
Browser security still matters.
Operating-system security still matters.
Network security still matters.
Payment authorization still matters.
Structural Plugin asks a narrower question:
Does this specific resolved action fit inside the authority declared for this specific task?
That is different from asking whether the user or application has broad permission to use the software at all.
The distinction is:
Structural Plugin admission != server authorization
and:
Structural Plugin admission != identity proof
and:
Structural Plugin admission != global safety
The existing security boundary remains independently authoritative.
🧾 What Happens After an Action Is Admitted or Refused?
Structural Plugin also treats the result as evidence.
The current reference produces deterministic evidence objects for supported paths, including identities for:
canonical actions
decisions
dependencies
receipts
verification entries
verification bundles
This means that a refusal can still be a valid result.
A stale action can still be valid evidence.
The principle is:
adverse outcome != invalid evidence
A correct refusal is not a system failure.
It may be exactly the evidence the system should produce.
🔍 Verification Without Trusting a Producer’s “PASS” Label
The current reference includes a browser implementation and a separate Python verifier.
The browser can produce a verification bundle.
The Python verifier can reconstruct supported decisions and evidence instead of simply trusting that the browser wrote:
PASS
The demonstrated paths include:
safe browser bundle -> Python PASS
stale browser bundle -> Python PASS
and:
deliberately modified bundle -> Python FAIL
The frozen decision corpus also produces:
14/14 PASS in browser
and:
14/14 PASS in separate Python verifier
The current claim is deliberately bounded:
separate implementation reconstruction = demonstrated
while:
third-party verification = NOT_CLAIMED
🌍 Where Could This Kind of Boundary Be Useful?
The same general question appears in many places.
An email assistant may need to draft but not send.
A document assistant may need to inspect but not delete.
A shopping assistant may search products but not purchase.
A financial assistant may prepare a transfer but not submit it.
A browser agent may read a page but not upload local files.
A business workflow may inspect records but not change account settings.
The broader question is:
Can software remain broadly capable without every task automatically inheriting those capabilities as action authority?
Structural Plugin explores one bounded answer:
full capability catalog -> task capability surface -> resolved action -> task authority -> revalidation -> execute OR withhold -> evidence
🧪 Current Reference Status
The current public release is Structural Plugin v0.3.0.
Published verification includes:
87/87 browser audit PASS
14/14 frozen vectors PASS in the browser
14/14 frozen vectors PASS in the separate Python verifier
12/12 permanent regression checks PASS
Safe verification bundle reconstruction PASS
Stale verification bundle reconstruction PASS
Deliberately modified bundle rejection PASS
The repository also includes a passing GitHub Actions deterministic verification workflow.
These results demonstrate the current published reference boundaries.
They do not establish universal correctness, production readiness, universal safe execution, or third-party certification.
⚖️ What Structural Plugin Does — and Does Not — Claim
Structural Plugin does not claim to control every action an application could perform.
It does not replace authentication.
It does not replace operating-system or browser security.
It does not guarantee protection against every form of prompt injection.
It does not establish legal authorization.
It does not establish payment authorization.
It does not make execution universally safe.
It does not claim production readiness by default.
Its question is narrower:
Can capability visibility and task-specific action authority be separated so that software remains capable without every task automatically inheriting unrestricted action authority?
The current reference explores that question within a declared mediated execution boundary.
🌐 Explore Structural Plugin
The repository contains the browser reference implementation, separate Python verifier, frozen decision vectors, schemas, verification bundles, architecture documentation, conformance rules, audit guidance, Quickstart, FAQ, and passing GitHub Actions verification.
🔗 Structural Plugin — Bounded Digital Action Authority on GitHub
For implementation, redistribution, documentation, architecture materials, and other use terms, refer to the repository’s Structural Plugin License.
The reference implementation and machine-readable verification artifacts may be used, copied, modified, tested, studied, and redistributed without a license fee subject to the license terms.
Documentation, architecture materials, specifications, diagrams, and explanatory content are governed by the separate terms stated in the same LICENSE, including applicable non-commercial use conditions.
🌌 The Larger Question
As software becomes more capable, the natural instinct may be to ask:
What can this system do?
Structural Plugin asks another question:
What should this particular task be able to see and do right now?
That distinction may become increasingly important as humans, AI agents, automation systems, and software tools begin sharing the same action surfaces.
The software may remain capable.
The task does not need to see everything.
A visible capability does not grant unrestricted authority.
A proposal does not become permission merely because it can be expressed.
And an earlier admission does not have to survive a meaningful change in state.
The principle is simple:
Keep software capable. Expose only what the task needs. Admit only what the task authorizes.
✍️ Authorship & Disclaimer
Created by the authors of the Shunyaya Framework.
Structural Plugin is a bounded deterministic reference architecture and implementation for task-specific capability visibility, digital action admission, current-state revalidation, and verifiable evidence.
It is not intended to replace authentication, application authorization, operating-system security, browser security, endpoint protection, network security, payment authorization, legal authority, organizational controls, or other production safeguards.
High-risk or production use requires independent verification, domain-specific validation, appropriate authorization controls, and suitable operational safeguards.
OMP
Comments
Post a Comment