Access Control and Permissions

The SIE operates on the principle of least privilege. Every actor in the system — human or agent — is granted only the permissions required to perform their defined role. No actor has unrestricted access. This constraint is not bureaucratic overhead; it is a direct implementation of the Bill Bernard Standard’s integrity requirements. Uncontrolled access is the fastest path to an ungovernable Knowledge Core.

Roles

The SIE defines four roles. Each role maps to a specific set of capabilities across the system’s layers: the Knowledge Core (Obsidian), the Knowledge Pipeline, the publishing layer (WordPress), and the agent fleet.

Fleet Commander

The Fleet Commander is the highest-authority human role in the SIE. This role has full strategic control over the system and is the only role that can perform certain irreversible or high-impact actions.

Capabilities:
– Read, write, and delete any content in the Knowledge Core
– Activate and archive content (change status to Active or Archived)
– Approve agent-generated content for activation
– Configure and deploy agents (roles, tools, prompts, Knowledge Core access boundaries)
– Modify governance protocols, quality standards, and pipeline configuration
– Trigger manual Knowledge Pipeline syncs
– Publish content to WordPress (direct publish, not just draft)
– Access all audit logs and agent action histories
– Manage other users’ roles and permissions

Constraints:
– All actions are logged. The Fleet Commander is not exempt from audit trails.
– Destructive actions (archiving content, deleting agents, modifying governance protocols) require explicit confirmation and are recorded with reasoning.

Content Steward

A Content Steward is a human contributor responsible for a defined domain of the Knowledge Core. Stewardship is assigned per-document via the steward frontmatter field, giving clear ownership over content quality and freshness.

Capabilities:
– Read all content in the Knowledge Core
– Write and edit content within their assigned domain (files where they are the designated steward)
– Submit content for activation (set status to Active for non-sensitive content)
– Respond to re-review flags for their stewarded documents
– View audit logs and agent action histories relevant to their domain

Constraints:
– Cannot activate high-sensitivity content (governance documents, agent protocols) without Fleet Commander approval
– Cannot modify governance protocols or pipeline configuration
– Cannot deploy or reconfigure agents
– Cannot publish directly to WordPress — content must pass through the Knowledge Pipeline

Agent

An Agent is an autonomous AI actor operating within the SIE. Agent permissions are the most tightly constrained in the system because agents act at machine speed — a misconfigured agent can cause damage faster than a human can intervene.

Capabilities:
– Read content from the Knowledge Core via RAG retrieval, scoped to the agent’s defined knowledge boundaries
– Create draft content (always with status: Draft and human_review_required: true)
– Execute defined tools (WordPress REST API, search, analysis) within the constraints of the Iron Word Verification Loop
– Log actions and attach Verification Ledgers to all outputs

Constraints:
– Cannot publish content. All agent outputs are drafts requiring human approval.
– Cannot modify existing Knowledge Core source files. Agents can propose changes by creating drafts; humans merge them.
– Cannot access content outside their defined knowledge boundaries. A Marketing Agent configured for the GROWTH domain cannot query CORE governance documents unless explicitly granted access.
– Cannot modify their own configuration, tools, or prompts. Agent reconfiguration is a Fleet Commander action only.
– All actions are subject to the Iron Word Verification Loop. An agent that attempts to execute a final action without the required Verification Ledger metadata is blocked by the tool layer.

Viewer

A Viewer has read-only access to published content. This role applies to WordPress site visitors and any external system consuming the published knowledge base.

Capabilities:
– Read published content on WordPress
– Access the public REST API endpoints for published knowledge base content

Constraints:
– No access to draft or under-review content
– No access to the Knowledge Core source files, audit logs, or agent histories
– No write access of any kind

Enforcement Mechanisms

Permissions are not enforced by convention — they are enforced by the systems themselves.

Git repository access controls who can commit to the Knowledge Core. The Fleet Commander has write access to all branches. Content Stewards have write access scoped to their domain directories. Agents do not have direct Git access; their drafts are staged through the agent tooling layer.

WordPress role mapping aligns with the SIE roles. The Fleet Commander maps to WordPress Administrator. Content Stewards map to Editor (with additional custom capability restrictions via the SIE plugin). Agents authenticate via WordPress Application Passwords with custom role restrictions that enforce draft-only creation.

Agent tool enforcement is the most critical layer. Every tool an agent uses (WordPress REST API wrapper, search function, file creation) is a controlled interface that checks the agent’s declared capabilities before executing. The Iron Word Verification Loop is hardcoded into the tool layer — it cannot be bypassed by prompt engineering or agent reasoning.

Audit logging captures every state change across all layers: Git commits, WordPress post status changes, agent actions, pipeline sync results, and permission changes. Logs are append-only and retained for the duration defined by the governance policy.

Multi-Site Considerations

When the SIE operates across multiple WordPress instances (e.g., adambernard.com, bernardhats.com, toppizzaonline.com), each site inherits the same role model but with site-scoped boundaries. A Content Steward for one site’s knowledge domain does not automatically have stewardship over another site’s content. Agent fleet permissions are configured per-site — the Marketing Agent for one site operates within that site’s Knowledge Core boundaries only.

The Fleet Commander role spans all sites, providing the unified strategic view required to manage cross-site content governance and agent fleet health.