Commonset Security Model

Security in Commonset has two jobs. The first is familiar: protect customer data, credentials, tenant boundaries, and privileged operations. The second is more specific to the problem we are building for: make security and governance claims about an AI capability continue to mean something as that capability changes, moves between systems, is reviewed by different people, and is distributed to different providers.

That second problem is easy to underestimate. A system can encrypt its database, authenticate every user correctly, and still have a weak trust model if an "approved" AI capability can change after review, if provenance can be rewritten, if provider distribution silently widens the intended audience, or if a clean security scan is treated as proof that an artifact is safe. For Commonset, security therefore includes conventional application controls and the integrity of the capability lifecycle itself.

The model starts with a fairly simple requirement: an organization should be able to determine what capabilities exist, who can access them, where they came from, which version was actually reviewed, what evidence informed the trust decision, and where that version can be distributed. Those answers should remain intelligible even when the model provider changes.

This page describes the controls Commonset currently implements and the boundaries of those controls. It is not a penetration-test report, compliance certification, or claim that automated analysis can prove an AI capability safe. Where we have architectural directions that are not generally available controls, I would rather say so explicitly.

Security boundaries should be explicit before controls are layered on top

The primary customer boundary in Commonset is the organization. Capabilities, versions, memberships, groups, grants, provider integrations, governance state, and the operations performed against them are associated with an organization, and tenant-scoped actions are expected to enforce that relationship rather than infer tenancy indirectly from some external provider object. This sounds mundane, but it is one of the most important properties of a multi-tenant governance system. If the tenant boundary is ambiguous, every higher-level claim about authorization, review, provenance, or distribution becomes less meaningful.

Authentication and authorization are deliberately separate. An identity provider can establish who a person is, but it should not become the canonical owner of Commonset's authorization model. Organization membership, capability permissions, review authority, and governance roles belong to the application domain. That gives Commonset room to support different authentication systems without coupling the underlying security model to one vendor's concept of an organization, group, or role.

Within that boundary, capability access is also more granular than a single member or administrator flag. Discovering that something exists, using it, reviewing it, and managing it are different operations with different consequences. Commonset represents those distinctions explicitly because least privilege becomes difficult if the permission vocabulary itself is coarse. The same principle applies internally. Platform operational privilege and customer-tenant authority are separate concepts. Operating the Commonset service should not, by itself, make someone an administrator of a customer's organization.

That boundary has been an area of active security work rather than an assumption we make because the data model appears tenant-scoped. We have performed focused tenant-isolation and authorization-path review, removed the generic Django administrator as a customer-data access path, and separated platform-operator privilege from tenant Owner/Admin authority. Those controls do not eliminate the need for continuing review as new provider and administrative workflows are added. They establish the direction: cross-tenant access should require an explicit defect, not emerge accidentally from an ambiguous ownership model.

Encryption matters, but the claim needs to be precise

Commonset protects capability data at the application layer rather than relying only on whatever encryption the underlying database or object-storage service provides. Trusted capability files are encrypted before they are handed to the configured storage backend, and the architecture uses organization-specific key material for capability content. Selected sensitive capability metadata is also protected at the application layer. Provider integration credentials are stored as encrypted ciphertext and decrypted by the application when an authorized provider operation requires them.

I think it is important to be equally specific about what that does not mean. Commonset does not claim that every operational field in the database is application-encrypted. Identifiers, hashes, timestamps, lifecycle state, routing data, and other information necessary to operate the service can have different storage requirements from capability content or sensitive metadata. Saying "everything is encrypted" would be easier marketing language and a worse description of the actual system.

Provider credentials deserve their own treatment because their security boundary extends beyond Commonset. A credential that can publish into an AI provider, repository, or external workspace is effectively a privileged machine identity. Encrypting it at rest is necessary, but it does not make an overly broad credential safe. The provider-side scope still determines what could happen if that credential were misused. For that reason, the security model assumes provider credentials should be scoped to the smallest workspace, project, installation, and set of permissions required for the integration.

The same precision applies to operator access. Our design objective is to minimize routine Commonset personnel access to customer capability content and sensitive metadata, and normal support should rely on operational information, minimized metadata, customer-provided reproductions, or explicitly authorized mechanisms where possible. We should not turn that objective into a stronger claim than the hosted architecture currently supports. Customer-controlled keys, customer-exclusive decryption boundaries, and customer-hosted trust processing are directions we are designing toward for customers that need stronger custody boundaries. They should be described as such until a particular deployment actually provides them.

Approval only means something if the approved object stays put

The capability lifecycle is where the Commonset security model differs most from a conventional content-management system.

An approval should describe a specific thing. If a reviewer approves Security Review v2.1, and someone later changes the instructions, files, or governed metadata, the resulting artifact is not still v2.1 in any meaningful governance sense. Commonset therefore treats approved versions as immutable. Changes belong in a new version that can be compared, analyzed, and reviewed independently.

That decision gives the rest of the trust model something stable to attach to. Commonset records an overall content hash and per-file hashes, and provenance can preserve source references, artifact relationships, parent versions, provider information, and transformation context. Review decisions belong to a particular version rather than to a mutable capability name. Security findings are also version-scoped. The result is that "approved," "reviewed," or "clean" can refer to a concrete revision instead of becoming a label that survives arbitrary changes to the underlying artifact.

Hashes and provenance are evidence, not magic. A SHA-256 value can tell us whether content matches content we previously identified; it cannot tell us whether the content is good. Provenance can tell us where an artifact came from and how it relates to another version; it does not prove that the source was trustworthy. An automated scanner can identify suspicious instructions, unsafe patterns, secrets, dangerous code, or other characteristics we know how to detect; it cannot establish the absence of every possible security problem.

That last distinction matters enough that we should state it plainly. Commonset's scanner and trust analysis are inputs into a governance decision. They are not substitutes for the decision. We have published a 250-case Agent Skill security evaluation comparing semantic review with Commonset's deterministic scanner, including the methodology, false positives, and the limits of what the reported results establish. Semantic analysis remains experimental until we have enough evidence to justify stronger production reliance on it. A product that tells a customer "AI says this is safe" has not built a serious security boundary.

This is also why trust state, access, and lifecycle state are separate. A capability can be visible without being broadly usable. It can be usable by its creator without being approved for organization-wide distribution. A version can be approved while a newer version remains under review. A security finding can block a particular version without erasing the identity and history of the capability. Those distinctions make the system more complicated than an approved=true field, but they preserve information that matters when someone later needs to explain what happened.

Distribution creates another security boundary

An authorization model can be correct inside Commonset and still produce the wrong result when a capability is pushed into an external provider.

The reason is that providers do not necessarily support the same audience model. Commonset may allow a capability only for a particular group, while a provider may expose the corresponding artifact to an entire workspace. If Commonset simply checks whether the API call is technically valid, the distribution can succeed while widening access beyond the organization's intent.

We treat that as a separate security decision. Before distribution, the system can consider the version's current trust and lifecycle state, the local audience, the capabilities of the provider connection, and the audience the provider will actually create. Approved-artifact integrity is also checked before distribution so the artifact being delivered corresponds to the governed version rather than merely sharing its name. A successful provider API response is therefore not sufficient evidence that the operation was appropriate.

This is one of the reasons provider-neutral identity matters for security as well as portability. Provider IDs remain useful mappings, but they should not become the only identity of the organizational capability. If a capability moves from one provider to another, its ownership, version history, provenance, review evidence, and intended audience should not disappear with the old provider record. The external systems remain execution and distribution environments. The organizational trust history remains attached to the capability.

Provider integrations also remain part of the shared-responsibility boundary. Commonset can enforce the controls available to it, but the customer still decides which external systems to connect, what scope to grant those credentials, what data users may provide to the provider, and whether that provider's own security and contractual controls are appropriate for the intended use. A governance layer can make those relationships visible. It cannot make an external provider less privileged than the credential or API that provider exposes.

A useful security model also describes its limits

I am wary of security documentation that consists entirely of statements about what a product protects. The places where a system deliberately stops making a guarantee are part of the model too.

Commonset can enforce tenant boundaries, permissions, immutable approved versions, encrypted storage paths, governance evidence, trust states, and distribution policy. It can make provenance and security findings available to the people making decisions. It can record important actions so that an organization can reconstruct who did what and when. None of those controls can guarantee that a capability will behave correctly under every model, that an external provider will satisfy a customer's security requirements, that automated analysis will find every malicious instruction, or that a broadly scoped provider credential becomes safe because Commonset encrypted it.

There are also assurance layers that should remain distinct from application security. Incident response, retention, backups, privileged-access review, change management, vulnerability management, SIEM delivery, customer-managed keys, and formal compliance evidence all matter to enterprise security. Some of that foundation exists today and some remains operational work or future product work. We should document those states accurately rather than allowing roadmap intent to become a present-tense product claim. Our own readiness work explicitly distinguishes controls that are implemented from those whose operational verification or implementation remains incomplete.

The principle underneath the Commonset security model is therefore not that one control establishes trust. Trust is composed from boundaries and evidence that remain intelligible over time: who the actor is, which organization they belong to, what they are allowed to do, which exact version is being considered, where that version came from, what changed, what automated analysis found, what a human approved, and where the resulting artifact is actually going.

If those facts are separable, inspectable, and tied to stable objects, an organization has something it can reason about.

That is what we mean when we say make trust visible.