Integrations and outbound data

Verified against v0.21.0 · cmd/parley/main.go, internal/auth/oidc.go, internal/standup/webhook.go, internal/plugin/fetch.go, internal/plugin/hostfn.go, internal/plugin/secrets.go, internal/api/embed.go, web/src/lib/meet.ts, web/src/pages/MeetAddon.tsx, ROADMAP.md, docs/integrations/split-publication-contract.md, internal/poker/publication/review.go, internal/poker/publication/run.go, internal/poker/publication/verify.go, internal/poker/publication/github.go, internal/poker/publication/github_project.go, internal/poker/publication/connections.go, internal/api/publication.go, web/src/components/SplitPublication.tsx, internal/plugin/secrets.go

Meeting content, retrospectives, plans, identities, and imported issue or repository data can be sensitive. Self-hosting describes who runs Parley; enabled integrations can still send data to other systems. Inventory the destinations and data for the configuration you actually run.

Current outbound paths

Path	Enabled by	Recipient and data	Operator action
Database	Required database configuration	Configured Postgres receives application records	Restrict access and protect transport, storage, and backups
OIDC	AUTH_MODE=oidc and provider configuration	Configured IdP: discovery/signing keys and sign-in token exchange	Review IdP, TLS, authentication and session policy; discovery is probed in the background at boot without gating startup or readiness, with sign-in retry after failure
Standup webhook	A configured space webhook	Configured HTTPS recipient: event, event ID, session URL, org and space slugs; no entry/blocker/participant text	Approve destination; protect signing secret; receiver verifies signature and deduplicates event ID
Plugin HTTP	Installed plugin with approved fetch grant and allowlist	Approved HTTPS hosts; request bodies/headers chosen by the plugin within its granted access	Review plugin, grants, and transmitted fields; revoke unwanted grants; retain egress controls
Google Meet add-on	Operator enables meet; user opens add-on	Browser loads Google SDK and uses Meet activity APIs, including main-stage URL and shared session ID	Review Google/Workspace deployment policy and add-on setup; this is not general Workspace data access

The core has no built-in telemetry, crash reporting, update checks, or model calls. Ordinary frontend assets and synthesized notification sounds are local. Optional plugin behavior must be reviewed separately. Provider, browser, proxy, log-shipping, backup, and operator-installed tooling can have additional data flows; this table does not attest to their processing or retention policies.

The plugin sandbox checks grants on each host call. Its HTTP guard screens every DNS result, dials the screened address, and repeats the checks for each redirect. Standup webhook delivery also uses that guard. An allowed hostname does not establish that sending arbitrary content to it is permitted. Plugins and webhook receivers must tolerate at-least-once delivery; a signature does not make duplicate messages new authority.

Connector acceptance criteria

Apply these requirements before shipping Jira import/write-back, wider Workspace access, GitHub issue integration, or any other connector. Jira estimate write-back and possible wider issue sync remain roadmap work; the existing Meet add-on does not imply a Workspace import connector exists.

1. Define operations and objects. List the exact provider objects, fields, endpoints, and purposes. Keep read-only import and write-back separately authorized. Request minimal provider scopes, explain their purpose, provide revocation, and use the provider’s required authorization flow for widening.
2. Bind credentials to scope. Resolve installations through the request’s authorized org and bind the org, space/workspace, connector instance, and authorized principal. Never select a token solely from an org/install ID supplied by the client. Foreign installs return 404 without disclosing existence. An org-admin check alone does not scope an object.
3. Authorize each use locally. Re-check role, membership, bound room, and object/field permissions before retrieval, display, search, export, or mutation. A broad service token does not give every member access to the provider content it can read. Jobs and retries carry and re-check their authorized scope; signed-link guests and embedded clients stay inside their route and room boundaries. Org custody remains management without access.
4. Decide cached-data semantics. Define upstream permission removal, deprovisioning, deletion, stale caches/search results, resync, and backup restoration. Record enforcement method and maximum lag. Do not call revocation immediate when copies remain readable.
5. Validate inbound authority. Use the provider’s webhook signature and callback/state verification rules. Bound replay acceptance, deduplicate events, and handle duplicate/reordered deliveries and expired authorization. A webhook payload cannot itself grant permissions or choose another tenant.
6. Constrain destinations and resources. Guard configurable URLs against SSRF, DNS rebinding, private/metadata addresses, unsafe redirects, and credential forwarding. Bound input/body sizes, timeouts, retries, queues, exports, and provider/model quotas. Reuse the host guard when integrating through plugins; document any required exception and compensating control.
7. Keep credentials private. Tokens and signing secrets stay out of browser bundles, meeting exports, logs, diagnostics, and model/agent context. Use scoped server-side storage and protect encryption keys separately. Test revocation, corrupt ciphertext, wrong scope/key, and interrupted rotation.
8. Retain evidence and user-facing documentation. A two-org fixture substitutes foreign IDs across read/list/update/export and asynchronous paths. Cover wrong roles, guest/embedded principals, forged callbacks, expired/revoked credentials, upstream removal, duplicates, SSRF/redirects, and secret leakage. Identify manual provider/configuration checks and outstanding limits. Behavior tests must be seen failing before the fix.

Optional GitHub split publication

GitHub.com ordinary-issue publication uses an encrypted connection bound to the current facilitator’s org, space, room and account. PLUGIN_SECRET_KEY is required; no plugin install is needed. Link guests, embedded clients and org custody are refused. Metadata read consent does not import remote meeting text; write permission is separate, and each exact payload requires review and consent. Replacement changes generation; revoke removes the PAT without deleting local operation identities or receipts. Prior review IDs remain issuer-bound.

The host verifies the repository, native ordinary parent, same-owner Project NUMBER field, complete bounded contents and parent absence. Numeric cards 1/2/3/5/8/13/21/34 map exactly; blank requires unset and cannot clear a default. Repository role and Project metadata do not guarantee every PAT endpoint grant: GitHub enforces actual token permission at each request, and outcomes remain separate. There is no remote text import, callback, webhook, background sync, completion retrieval or issue deletion.

Outbound calls use guarded fixed api.github.com with no redirects. Scope, current role/membership, generation and provider access are rechecked on each step. Requests have a 60-second cumulative deadline and durable bounded leases. GitHub has no conditional field update, so another writer can race preflight. Project automation can change values or membership later; no permanent automation exclusion is claimed. Ambiguous deletion or lost access pauses delivery, with no cached remote issue text exposed. Local access denial clears open review and receipt views; confirmed receipts describe historical readback, not current upstream access.

Create, parent, Project membership, estimate and each directed dependency/removal retain separate exact readbacks. Unknown creation cannot authorize a blind second create. Deliberate refresh requires the issuer’s current local authority and live scoped connection. Confirmed issues are reused without rewriting their text. See the planning poker guide and receipt boundary for configuration, uncertainty and retained history. This is one reviewed handoff, not full synchronization or a promise about Jira.

Model-facing features and telemetry

If model-facing recaps or synthesis are added, document exact destinations, fields, purpose, provider retention/training settings, human access and region from actual terms/configuration before claiming locality or confidentiality. A bring-your-own endpoint can be external. Make outbound model calls and any telemetry visible and configurable; document the fields and recipients.

Imported issue text, meeting notes, plugin output, or retrieved context is untrusted data. It cannot expand tool permissions, change tenant scope, or choose an arbitrary exfiltration destination. Enforce authorization outside the model and preserve the user’s authorization for external actions. Prompt filtering/evaluations supplement deterministic policy tests.