mdBoard
Menu
GuideDocsOfferingsWhy mdBoardGitHubGet a licence

Security

mdBoard coordinates a private repository. Treat it as a local developer tool, not a multi-tenant service.

The trust model in one paragraph

The human talks to a agent. The agent uses mdBoard and holds the upstream writer lease. mdBoard records the human decisions and enforces the state machine, but it does not sandbox the agent. Chat-only authorisation is an audit convention: it records who authorised what, but a misbehaving agent with repository write access could forge the record. Branch merges and releases are human-executed.

What mdBoard does protect

  • Card-level authority: human-gated actions require an actor and, for agent execution, the human authoriser and statement.
  • Review independence convention: the reviewer must not be the intent owner; the owner makes the final accept.
  • One writer lease: two agents should not write the same upstream.
  • Branch boundaries: only the owner executes upstream → nightly and nightly → stable.
  • Local HTML auth: one-time token, HttpOnly SameSite cookie, CSRF token and Origin check.
  • Owner-only files: configuration, actors and the roadmap override are owner-controlled.
  • Plugin default closed: manifests are digest-pinned and owner-locked; execution is disabled in this alpha.

What it does not protect

  • It is not a hardened internet-facing service. There is no OIDC, trusted-proxy mode, rate limiting or multi-tenant isolation.
  • It does not prove a chat approval happened. The event is evidence, not a signature.
  • It does not prevent a malicious local user or agent with repository write access from editing files.
  • It does not execute plugins, so there is no plugin sandbox claim.
  • Sessions are in memory; restarting the server logs everyone out and there is no central revocation log.

Run serve on 127.0.0.1 and use SSH port forwarding for remote access. Do not bind it to a public interface.

  • Keep the repository private.
  • Use Git hosting branch protection for upstream, nightly and stable.
  • Give the agent write access to upstream only; never merge rights to nightly or stable.
  • Run mdboard check --git and mdboard render --check in CI.
  • Keep the owner-only files under human review.
  • Review the event journal after a suspicious action.
  • Do not put credentials, customer data or personal data in cards, reviews or reports.

Chat-only approval

The current mode records:

actor: agent
executor: agent
authorised_by: owner
authorization: "Yes, accept the batch."

This is enough for a trusted team and an auditable workflow. It is not enough to defend against a agent that ignores the runbook while holding filesystem access. If you need stronger separation, keep human approvals in the HTML board or run high-risk actions in a human-owned terminal, and treat the event record as evidence rather than proof.

Secrets

mdBoard has no secret store. Cards, events, reviews, meetings and reports are committed to Git. Do not put tokens, private keys, customer data or personal data in the board.

If the agent needs a credential to run a task, it should obtain it from the environment or a secret manager, not from a card.

Plugin risk

Plugins are declared, digest-pinned and owner-locked, but not executed in this alpha. A verified plugin is not sandboxed. Future execution needs a real isolation boundary before the documentation can make a security claim.

Next