Security & guardrails

The boundaries that keep an automated agency assistant safe. Get these right before you put a runner in production.

Human approval on outbound

Prscnt drafts but never sends. Outreach, contracts, and invoices are produced for a human to approve and ship through your own connector. In a headless runner there's no human in the chat, so the approval prompt is replaced by a code gate:

• The template's canUseTool allows read/intel and pipeline work and blocks anything that sends or deletes externally, returning it as a proposed action.
• Your UI shows the proposed action; a manager approves; only then does it execute.
• ALLOW_OUTBOUND=1 disables the gate — set it only if you enforce approval somewhere else.

Never wire an unattended agent straight to "send email" or "sign contract." A brand inbox is not a place for an unsupervised loop.

Read vs. mutating, again

Intelligence tools are safe to call from automation. Mutating tools (deals_update_stage, deals_bulk_create, the invoice_* and roster_* writers, voice indexing) change state and should be deliberate. When in doubt, have the agent propose the change and let a human confirm.

Credential boundaries

• Your connectors run with your keys, on your side. Prscnt never receives your Gmail, QuickBooks, Airtable, or HubSpot credentials. It composes those tools only through your MCP in the agent's session.
• Prscnt holds pointers, not data. The only Prscnt-side record of your external systems is a deal-to-record pointer (id + URL). Your customer data stays in your accounts.
• What Prscnt stores about you is your workspace state (roster, deals, voice profile, contract playbook) and contributions you opt into. privacy_summary returns a plain-language breakdown of what's stored, what's shared-anonymized, and what never leaves.

Workspace isolation

Your bearer token resolves exactly one workspace, server-side. You can't read another tenant's data, and you must never pass a workspace_id from the client — a mismatched id is rejected (WORKSPACE_MISMATCH). Treat the token like a password.

Securing your runner

If you run the orchestration runner, it's a public door to your API credits and your data. Before exposing it:

• Set RUNNER_TOKEN and send it as x-runner-token from your UI. Without it, anyone who finds the URL can trigger agent loops on your dime. The template rejects untokened requests when it's set.
• Put it behind HTTPS. It carries keys and acts on data.
• Give it its own seat key, so you can meter and revoke that caller independently of your humans.
• Keep the timeout. RUNNER_TIMEOUT_MS aborts stuck runs so your UI doesn't retry one task into duplicate work.
• Don't log keys. Keep ANTHROPIC_API_KEY and PRSCNT_API_KEY out of logs and error payloads.

Shared intelligence is anonymized

The market intelligence you read is a composite — aggregated across many observations with minimum-sample thresholds — never a raw passthrough of any single party's data. You benefit from the corpus; no individual deal is exposed.

A safe-by-default checklist

• Outbound gate on (ALLOW_OUTBOUND unset) unless you have your own approval step.
• RUNNER_TOKEN set and required.
• Runner behind HTTPS.
• A dedicated seat key for each automated caller.
• Mutating tools surfaced as proposals, not auto-executed.
• Keys kept out of logs.
• 429 / paywall_denied handled gracefully.

Next

• Back to the Overview, or jump to Recipes to start building.
• Questions: support@prscnt.com.