Your marketplace invites third-party apps into a platform holding board data. That is an attack surface most mature vendors get wrong. What is the trust model?

The full executive answer

The trust model is least-privilege by construction, and deliberately conservative for the product’s stage. Partner apps cannot ask for arbitrary access: they request scopes from a fixed registry of eight read-only permissions — latest scorecard, active roadmap, risk register, compliance posture, vendor portfolio, talent assessment, score history, and the deterministic signal set. No write scope exists in the registry at all today. At install, the customer grants a subset of what the app requested — requesting a scope does not confer it — and invalid or unknown scopes are rejected structurally. Credentials are hashed, not stored raw.

Beneath the scope layer sit the platform’s standing controls: every tenant’s data is isolated by database-level row security, so a marketplace credential is bounded by the same tenancy walls as everything else; access is auditable; and the scopes deliberately mirror our public API’s read scopes, so there is one permission model to review, not two. For your threat model, the maximum blast radius of a fully compromised marketplace app today is: read access to the specific artifact classes one customer explicitly granted, for that customer’s org only.

Roadmap, stated as roadmap: write scopes will exist eventually — an ecosystem that can never act is a reporting feed — but they arrive behind a partner review process and per-scope customer consent, not before. The empty marketplace catalogue is, for once, a security feature: you are evaluating the architecture before any third party has been let in, which is exactly the right order.