Commonset Security Architecture

Security is part of Commonset's product behavior, not a separate compliance layer added after capabilities are created.

The platform is designed around a simple requirement:

An organization should be able to understand what AI capabilities exist, who can access them, where they came from, what was approved, and where they can be distributed.

This security architecture guide describes implemented Commonset controls, the boundaries of those controls, and longer-term security direction.

It is a product architecture overview, not a security certification, penetration-test report, or compliance attestation.

1. Organization Is the Primary Tenant Boundary

Commonset models the organization as the primary customer boundary for:

• capabilities
• versions
• memberships
• groups
• access grants
• provider integrations
• governance state
• audit activity

Tenant-scoped records carry an organization relationship, and access rules validate that users and groups belong to the same organization as the capability they are granted.

The security objective is that customer-scoped queries, jobs, storage references, and administrative actions respect explicit organization boundaries.

2. Authentication and Authorization Are Separate

Commonset uses an identity provider to authenticate users, but the external identity provider is not the owner of Commonset's authorization model.

Organization membership, roles, capability grants, and governance permissions belong to Commonset's application domain.

This provider-neutral identity design makes it possible to change or add authentication providers without rewriting the core authorization model.

It also reduces the risk of treating an identity-provider organization object as the canonical Commonset tenant.

3. Capability Permissions Are Explicit

Commonset capabilities have distinct permissions:

• Discover
• Use
• Review
• Manage

Grants can target an organization, group/team, or individual user.

This gives Commonset a least-privilege vocabulary instead of relying only on broad administrator/member roles.

Permission semantics should remain explicit. Discovering that a capability exists is conceptually different from reading or executing its full content, reviewing it, or managing new versions.

4. Application-Level Encryption Protects Capability Data

Commonset applies encryption inside the application before sensitive capability data reaches the underlying persistence layer.

Capability files

Trusted capability files are encrypted before Commonset hands them to the configured storage backend. Each organization uses a random, versioned data-encryption key for capability-file content. The organization key is wrapped by deployment key material rather than stored as plaintext.

Encrypted capability objects do not expose direct storage URLs through Commonset's encrypted storage layer.

This means protection of the capability artifact does not depend only on whether the storage provider or disk volume also offers encryption at rest.

Sensitive capability metadata

Selected sensitive metadata is encrypted at the application field layer, including capability names, descriptions, version frontmatter, and release notes.

Metadata uses authenticated AES-GCM encryption with a 256-bit per-organization data-encryption key. Authentication context binds ciphertext to the organization, model, record identity, and field so moving an encrypted value to a different tenant, row, or field does not produce valid plaintext.

Per-organization metadata keys are versioned and wrapped by a metadata-specific key-encryption key derived from deployment master key material.

Encryption boundaries

Commonset does not claim that every operational database field is application-encrypted. Identifiers, slugs, lifecycle states, hashes, timestamps, and other fields needed for indexing, integrity, routing, or operations may remain ordinary database data. The stronger application-level encryption is focused on capability content and selected sensitive metadata.

This distinction is intentional: customer-facing encryption claims should describe the data actually protected by the deployed architecture rather than implying that every field uses the same encryption mechanism.

5. Provider Credentials Are Encrypted Separately

Provider integrations store credentials as encrypted ciphertext rather than plaintext application fields, using a separately configured integration-encryption key. Commonset retains only limited credential hints for display.

Credentials are decrypted by the application when they are required for an authorized provider operation.

Provider credentials should be treated as privileged machine identities and scoped to the smallest provider workspace or project and permissions needed for the integration.

The current credential encryption path is separate from the per-organization capability key hierarchy. Moving provider credentials to per-organization envelope encryption and managed key infrastructure is a security-hardening direction, not a capability Commonset should claim as implemented today.

Compromise of a provider credential can have a distribution blast radius outside Commonset, so credential scope is part of the security model, not just setup convenience.

6. Approved Versions Are Immutable

A core governance control is version immutability.

After a version is Approved, Commonset prevents its content hash, governed metadata, and files from being changed in place through the application model.

Files cannot be added to, changed within, or removed from an approved version.

If behavior needs to change, create a new version and review it separately.

This protects the meaning of approval:

The content associated with the approved version remains the content the reviewer approved.

7. Integrity Identifiers Support Verification

Commonset records:

• an overall version content hash
• per-file SHA-256 values
• artifact or source hashes in provenance where available

These identifiers provide a basis for comparing revisions, detecting unexpected changes, and strengthening distribution-time integrity checks.

Hashes are evidence; they are most valuable when validation and distribution paths consistently verify against them.

8. Provenance Is Append-Only Governance Context

Each concrete version can have a provenance record describing where it came from.

Provenance can include:

• origin
• source reference
• artifact hash
• content hash
• parent version
• actor who recorded it
• provider or transformation metadata

In the current application model, provenance records are append-only: existing provenance cannot be edited or directly deleted through the model.

This helps prevent a version's history from being rewritten after the fact.

9. Review Decisions Are Durable Evidence

Review requests and decisions are attached to a specific version.

A terminal review decision records the reviewer, decision, comment, and time.

Current application safeguards treat review decisions as immutable governance evidence rather than editable notes.

This supports separation of duties and allows an organization to reconstruct why a version became Approved or why changes were requested.

10. Security Analysis Is Version-Scoped

Commonset records security scans and findings against a particular version.

Trust/security states include:

• Pending
• Clean
• Warning
• Blocked
• Error

Findings can include severity, category, file path, line number, description, and supporting metadata.

The purpose is not to claim automated scanning can prove a capability safe. It is to make technical evidence part of the same version-specific governance workflow as review and approval.

11. Trust, Access, and Availability Are Composed

Commonset does not equate a clean security scan with permission to use a capability.

Effective runtime availability can depend on:

• lifecycle state
• review status
• security/trust result
• creator ownership
• capability grants
• organizational policy

A trusted creator-only draft can therefore remain available to its creator without becoming Approved for the organization.

This helps preserve developer velocity while keeping broader trust explicit.

12. Provider Distribution Is a Separate Security Boundary

A provider can have a broader audience model than Commonset.

For example, a provider surface may publish a skill at workspace scope while Commonset grants allow only a team.

Commonset treats provider distribution as an independent policy gate.

Before publication, the system can evaluate:

• Commonset approval and current trust
• provider connection capabilities
• local access scope
• provider audience scope
• whether an explicit distribution exception is required

A successful API call is not sufficient if it would widen access beyond organizational intent.

13. Provider-Neutral Architecture Reduces Lock-In Risk

Provider IDs and provider versions are stored as mappings to Commonset capability/version identity.

This has a security benefit as well as a portability benefit: governance evidence does not disappear merely because the organization changes AI providers.

Ownership, review, provenance, and access remain part of the Commonset record.

14. Auditability

Commonset records security- and governance-relevant events across application workflows, including provider and MCP operations.

Audit data should answer who performed an action, against which organization or capability, and when.

The product direction is to make authorized in-product audit visibility part of the core governance experience so customers can understand important approvals, policy decisions, distribution exceptions, identity changes, and privileged actions without relying on Commonset operators.

Long-term audit hardening—such as stronger append-only storage, tamper-resistant retention, advanced export/compliance evidence, and external security-event delivery—should be treated as separate assurance layers and documented accurately as they are implemented. The commercial direction is for SIEM integration / security-event streaming to be an Enterprise capability, while ordinary authorized audit visibility remains part of the trust foundation.

15. Commonset Operator vs. Customer Administrator

A customer administrator and a Commonset platform operator are different security roles.

The architectural direction is that operating the Commonset service should not automatically imply routine access to customer capability contents or sensitive metadata.

Preferred support patterns include:

• diagnosing from operational logs and minimized metadata
• customer-provided reproductions
• explicitly authorized, scoped support mechanisms where necessary
• avoiding standing broad access to raw customer capability content

This is an important design requirement and direction. It should not be overstated as a guarantee that no authorized Commonset system or personnel could ever access customer data in the current hosted architecture.

16. Customer Content Ownership

Commonset's product principle is that customer capability intellectual property remains the customer's.

Commonset requires the limited rights necessary to process content to provide the service, but the capability itself should remain an organizational asset rather than becoming locked to Commonset.

Portability and exportability should remain architectural requirements.

17. Customer-Controlled Storage and Keys

Commonset is designed to preserve a path toward stronger customer control, including concepts such as:

• customer-owned cloud or object storage
• private deployment patterns
• customer-managed encryption keys / BYOK
• stronger customer-controlled revocation boundaries

These are security roadmap directions unless and until a specific deployment offers them.

They should not be represented as generally available controls before implementation and validation.

18. Analytics and Privacy

Capability analytics should collect the minimum information needed to understand adoption, operational health, and value.

The security direction is to avoid collecting raw capability content simply to produce usage metrics.

Retention, aggregation, and customer controls should be explicit rather than accidental byproducts of logging.

Shared Responsibility

Commonset can provide governance and technical controls, but customers remain responsible for decisions such as:

• which provider credentials to connect
• how broadly those provider accounts are scoped
• who receives review/manage permissions
• what risk is acceptable for a particular capability
• what data users supply to AI providers
• which provider terms and security controls are appropriate for their use

Security Principles

The Commonset security model can be summarized as:

1. Explicit tenant boundaries.
2. Least privilege for humans and integrations.
3. Separate authentication from domain authorization.
4. Encrypt sensitive capability data and provider credentials.
5. Keep approved versions immutable.
6. Preserve provenance and governance evidence.
7. Treat automated scanning as evidence, not automatic approval.
8. Keep Commonset access distinct from provider distribution scope.
9. Minimize routine operator access to customer capability data.
10. Preserve a path toward customer-controlled storage and keys.

The broader product principle is the same as the UX principle:

Make trust visible.