Security

Least access, project separation, and human approval

The security model applies across the portal, API, and operational MCP.

01

Identity and authorization

  • Human session for the portal and OAuth 2.1 with PKCE consent for compatible connectors.
  • Permissions are separate: read queries data, write prepares changes, and approve lets a person decide on the exact proposal.
  • Only the account owner or an administrator can authorize approvals; existing connections must be authorized again before their permissions expand.
  • dpk_ and dpa_ are revocable advanced options but can never approve.
02

Approvals inside the agent

  • Every card uses a redacted snapshot, version, SHA-256 hash, and expiry issued by the server.
  • Approval rechecks role, grant, plan, limits, provider, version, and hash and executes exactly once.
  • ChatGPT uses an app-private MCP decision tool, Claude uses native confirmation, and other clients may use elicitation.
  • The portal retains history, policies, and revocation and acts as fallback when a client cannot embed human interaction.
03

Data and secrets

  • Queries scoped to the authorized project.
  • Provider credentials encrypted at rest.
  • Private account, project, lead, campaign, credential, and audit data is not authorized for model training.
  • The commercial MCP never contains customer data.
04

Report a vulnerability

Email security@digitalpublic.com. Do not include unnecessary secrets or personal data. We will acknowledge receipt and coordinate responsible validation.

Machine-readable evidence

The same facts are available through API and MCP.

OpenAPI