Safety Through Boundaries

Principle XI: Safety Through Boundaries

Safety through boundaries, not trust.

“We trust our engineers” is the most expensive sentence in information security. Not because the trust is misplaced — most engineers are trustworthy — but because trust is a policy, not a mechanism. Policies are aspirational. Mechanisms are enforceable. Obsidian builds safety from mechanisms.

Zero Trust for Secrets

Every secret in Obsidian — API keys, credentials, tokens — is accessed through a boundary layer that logs the access, verifies the permissions, and enforces the scope. No agent has ambient access to secrets. No agent inherits credentials from its parent without explicit declaration. The access is logged. Always.

This is not paranoia. This is accounting. You log financial transactions not because you assume everyone is stealing, but because accountability requires a record. Secret access is the same: the log exists for the day you need it, and you will need it.

Sandboxed Execution

Plugins and extensions execute in sandboxes. Not “sandboxes” in the marketing sense — where the sandbox is a promise and the escape hatch is a flag — but actual execution boundaries with declared capabilities and enforced limits.

A plugin that declares file system access gets file system access within its declared scope. A plugin that does not declare network access does not get network access. There is no “sudo mode.” There is no override. The boundary is the boundary.

Declared Permissions Over Implicit Access

Every capability in Obsidian is explicitly declared. An agent specifies what it needs — file access, network access, model access, delegation authority — and receives exactly that. Not more. This is the principle of least privilege applied with architectural rigor rather than administrative hope.

The Warden enforces these declarations at runtime. An agent that attempts to exceed its declared permissions does not receive a warning — it receives a denial and a constitutional compliance violation. This strictness is a feature.

Audit Trails for Accountability

Every permission check, every secret access, every boundary enforcement is recorded in an immutable audit trail. This trail is not optional. It is not configurable. It exists because Safety Through Boundaries without accountability is just security theater with better architecture.

The audit trail answers three questions at any point in time: who accessed what, when did they access it, and were they authorized to do so. If you cannot answer all three, you do not have security — you have hope.

Implications

Security in Obsidian is not a layer applied on top of functionality. It is woven into the architecture at the same level as the Constitution itself. Every new feature, every new plugin interface, every new agent capability must answer the boundary question before it answers the functionality question.

Relationship to Other Principles

Safety through boundaries is the enforcement mechanism for Autonomy Under Constraint (Principle VII) — boundaries are how constraints become real. It depends on Observable by Default (Principle V) for the audit trail infrastructure. And it protects the integrity of Constitutional Consensus by ensuring that agents cannot subvert the consensus mechanism through unauthorized capability escalation.