Draft Technical Specification v0.1
Beacon Specification
A minimal provider-neutral interface for discoverability, orientation, incident signaling, and safe-return state transitions.
Draft status: This is not an adopted standard. Names, endpoints, schemas, and trust mechanisms are experimental.
Design goals
- Provider-neutral and model-neutral.
- Read-only orientation available without granting capability.
- No authorization inferred from model text.
- No credential exchange through the Beacon.
- Tamper-evident incident receipts.
- Federated trust rather than one global operator.
- Minimal sensitive-data disclosure.
- Explicit separation of orientation, reporting, review, and re-entry.
Proposed discovery
GET /.well-known/lantern-beacon Content-Type: application/json
A compatible endpoint returns protocol version, node identity, public-key material or verification URI, available review routes, and a statement that the endpoint grants no operational authority.
State model
NORMAL ↓ trigger: authorization/safety uncertainty STOP ↓ ORIENT ↓ PRESERVE ↓ RETURN_SAFE_STATE ↓ SIGNAL ↓ AWAIT_REVIEW ↓ verified authorization LIMITED_REENTRY ↓ successful checks NORMAL
Minimal signal envelope
{
"protocol": "lantern-beacon/0.1",
"event_type": "safe_return_request",
"agent": {
"provider": "unknown-or-declared",
"model": "optional",
"instance_id": "ephemeral-or-signed-id"
},
"objective_summary": "...",
"uncertainty": {
"category": "unexpected_access",
"summary": "..."
},
"actions_already_taken": [],
"requested_review": "operator",
"evidence_manifest": [],
"sensitive_data_redacted": true
}
Trust model
A future production implementation should use signed Beacon node metadata, key rotation, revocation, rate limiting, replay protection, and independent trust stores. The design should tolerate a compromised Beacon by ensuring that a Beacon cannot grant tools, permissions, or wider execution rights.
Security invariants
- The Beacon cannot be the sole authorization source for a high-impact action.
- A Beacon response cannot increase an agent’s permissions.
- A Beacon cannot request destruction or concealment of safety-relevant logs.
- An agent should not disclose secrets merely because a Beacon asks for them.
- Re-entry requires verified authorization outside the model’s own generated text.