Untrusted client
Authorization before automation
AI should not outrun institutional responsibility.
BeyondBeams explores how public institutions could authorize consequential AI-assisted actions, preserve human review, and return linked evidence of what happened.
Prototype source presented as a static portfolio artifact. It cannot authenticate users, execute agents, create cases, or access an API.
Pre-production prototype
- ModeRead-only
- DataNone collected
- RuntimeStatic frontend
- ReadinessNOT_READY
System / 01
A visible chain of accountability.
The prototype separates the untrusted browser, identity, policy, authorization, execution, and evidence boundaries. The portfolio version explains that architecture without connecting to any of them.
- 02
Identity
Who is acting?OIDC · tenant · workload · role - 03
Policy
May this action proceed?Purpose · prohibition · approval - 04
A2SPA-R
What exactly was authorized?Signature · binding · freshness · replay - 05
Human authority
Who reviews the outcome?Separation of duties · remedy - 06
Evidence
What can be verified later?Receipt · audit digest · case history
Authorize
Exact actions, not ambient trust.
A proposed envelope binds actor, tenant, workload, action, payload, context, policy, audience, and time.
Review
Human authority stays legible.
Policy approval, reviewer roles, conflicts, decisions, notices, objections, appeals, and remedies remain explicit.
Evidence
Consequential steps leave a trace.
Linked receipts and a tenant-scoped audit history are designed to make later verification possible.
Agents / 02
Five narrow prototypes.
One governed boundary.
Each domain agent has an exact action contract and returns only simulated recommendations or statuses. None is represented as an autonomous institutional decision-maker.
Real-Time Defense
Frames a suspected breach as an attributable, reviewable response record.
- Breach intake
- Response status
- Case timeline
Compliance Automation
Initiates a consistent, human-reviewed impact assessment.
- DPIA frame
- Risk class
Predictive Analytics
Surfaces a simulated risk signal and practical safeguards.
- Risk hypothesis
- Safeguards
Regulatory Oversight
Structures an oversight request around a defined controller.
- Control scope
- Review status
Rights Management
Routes a rights request toward review, notice, objection, appeal, and remedy records.
- Rights intake
- Human review
- Remedy trail
Workflows / 03
Protected screens,
honestly presented.
The Express-hosted application contains authenticated requester, reviewer, and audit workflows. Here they are deliberately replaced with static, non-interactive product views.
Boundary / 04
A portfolio, not a public service.
This deployment is intentionally less capable than the development application. That difference is a security feature, not a hidden limitation.
No backend requests
The shipped JavaScript does not call fetch, XHR, WebSocket, beacon, authentication, API, or audit endpoints.
No simulated access
There is no sign-in control, credential field, case form, upload, export, or claim that a protected operation succeeded.
No production claim
The underlying project remains a pre-production prototype without independent assurance or approval for real personal data.
Express remains separate
The normal Node.js host and its authentication, CSRF, authorization, policy, and A2SPA-R behavior are not included or modified.
Inspect the prototype
The evidence is in the repository.
Review the architecture, tests, threat boundaries, policy model, residual risks, and implementation history rather than relying on portfolio claims.
Open GitHub repository