Commonset for Security and IT Teams

Security and IT teams are being asked to govern AI at an awkward point in its development. The underlying platforms are changing quickly, adoption is often happening before a centralized operating model exists, and employees are no longer using AI only through isolated conversations with approved chat applications. They are building reusable prompts, skills, agents, workflows, tools, and integrations that encode how work gets done. Some of those artifacts stay personal. Others are shared with a team, copied between systems, connected to enterprise data, or quietly become dependencies in recurring business processes. The organization can approve the provider and still know very little about the reusable behavior employees have created inside it.

That creates a governance problem that is different from deciding whether an application belongs in the SaaS portfolio. Security may know that Claude is approved, that a particular OpenAI tenant has passed vendor review, or that employees authenticate through managed enterprise accounts. Those are necessary controls, but they do not answer which skills have been created, where a particular agent came from, who owns a workflow, what changed since it was reviewed, which version is actually in use, what permissions it has, or whether the provider is exposing it to more people than the organization intended. Increasingly, the application is the execution environment. The capability built inside it is the thing carrying the organization's behavior.

Commonset is intended to give Security and IT an organizational control layer for that second problem. The objective is not to replace provider security controls, identity systems, endpoint controls, SIEM, or the other infrastructure these teams already operate. It is to provide a stable place to reason about reusable AI capabilities across those boundaries: what exists, who is responsible for it, where it came from, which revision has been evaluated, what evidence exists, who should be able to use it, and where that version has actually been made available.

That distinction is important because the organization eventually needs an answer that is broader than "this AI provider is approved." It needs to know whether this capability, in this version, for this audience, with these permissions, in this environment is something it is prepared to rely on.

Visibility has to come before control

The first problem is inventory, but inventory in AI is more complicated than listing applications.

Traditional SaaS discovery can tell you that an employee is using a particular service. That is useful because the application is often the relevant unit of control. Reusable AI introduces another layer inside the application. Two employees can use the same approved provider while one is conducting low-risk research and the other has built an agent with access to sensitive data and the ability to modify business records. Conversely, ten provider artifacts may all be implementations or copies of one organizational capability.

Security therefore needs visibility at the capability level, not only at the provider level.

Where supported provider APIs and connected credentials expose the necessary information, Commonset can synchronize provider inventory and associate those records with organizational capabilities. The boundary matters. Commonset cannot see systems that have not been connected, provider objects that an API does not expose, or resources outside the scope of the credential it has been given. A serious inventory should make that incompleteness visible rather than presenting a partial provider view as though it were the whole organization.

The first useful outcome of discovery is not necessarily approval. It is simply knowing that something exists.

That sounds obvious, but it has important implications for how Security and IT should design the operating model. If discovering an employee-created capability automatically disables it, registration becomes punitive. The organization has created a strong incentive for useful work to remain outside the governed system. Unknown, unreviewed, and unsafe are not synonyms. Something may deserve restriction once evidence establishes risk, but the act of making it visible should not itself be interpreted as proof that it is dangerous.

This is particularly relevant to Shadow AI. The shadow is not limited to personal ChatGPT accounts or unsanctioned AI vendors. A reusable capability can exist completely inside an approved enterprise platform and still be effectively invisible to the organization if nobody knows who created it, who is using it, which revision is current, or what systems it can affect. Security may have approved the container while having no organizational record of what employees have built inside it.

A useful first response is therefore to establish identity, ownership, provenance, and context. Who created this? Was it imported from a repository or built directly inside a provider? Does it correspond to an existing organizational capability? Which team depends on it? What data and tools can it reach? Is it an experiment, a shared team asset, or something that has already become operationally important?

Once those facts exist, control can become proportionate instead of reflexive.

Trust has to attach to a version, not a name

The next problem is that the objects being governed change.

A workflow called Contract Review may exist for a year, but that does not mean the thing called Contract Review has been stable for a year. Instructions change. Files are added. Tools gain permissions. Dependencies move. Someone imports a new version from a repository. A provider copy is modified directly. A model-specific implementation diverges from the source the organization originally reviewed.

This makes version identity a security primitive.

If Security approves Contract Review v2.3, the evidence supporting that decision belongs to v2.3. It should not silently become evidence for v2.4 merely because the capability has the same name. Commonset treats approved versions as immutable so that a review continues to refer to a stable object. Changes create a new version that can be compared and evaluated on its own terms. The practical benefit is not versioning for its own sake. It is that "approved" continues to mean something after the artifact evolves.

The same reasoning applies to automated security analysis. Commonset records findings against the version that was analyzed. A finding can point to a file, category, severity, or other evidence relevant to review, but automated analysis should not be mistaken for the final trust decision. A clean scan is evidence. It is not a proof that a capability is safe. A warning is also evidence. It is not necessarily proof that the capability must be blocked. We have published a 250-case Agent Skill security evaluation showing how our semantic review procedure and deterministic scanner behaved across adversarial and regression cases, including where false positives and uncertainty still matter.

Context matters. An instruction that deserves investigation in a broadly distributed production capability may be acceptable in a narrowly constrained research workflow. Executable content, external tools, credentials, dependencies, and expanded permissions may materially change the review required. The important thing is that the system preserves enough evidence for a reviewer to understand what they are deciding rather than reducing the result to a generic green checkmark.

Provenance contributes a different kind of evidence. Security should be able to understand whether a capability was created internally, imported from GitHub, discovered in a provider account, derived from a previously approved version, or transformed during distribution. Content hashes and source references help establish relationships between artifacts. They do not prove that the source itself is trustworthy, but they make the history inspectable.

Ownership then answers the organizational question that technical evidence cannot: who is responsible for this capability continuing to make sense? A shared AI capability without an accountable owner can become an operational dependency whose assumptions, permissions, or source material gradually become outdated without anyone noticing. Assigning ownership is not paperwork added to the development process. It is how the organization makes responsibility durable when the artifact begins to outlive the person who created it.

The result is a trust model built from several pieces rather than one status field: lifecycle state, version identity, provenance, automated findings, human review, ownership, access, and intended use. Security and IT do not need every capability to receive the same review. They need enough structure to identify when a capability has crossed a boundary that justifies more scrutiny.

Access inside Commonset and access inside the provider are different problems

One of the less obvious problems appears when a governed capability leaves the control plane and enters a provider.

Suppose Commonset says that a capability is available only to the Legal team. The target provider may support exactly that audience, in which case distribution is straightforward. But a provider may instead expose the artifact at workspace scope. The API call can succeed technically while producing an authorization outcome the organization did not intend.

That is why distribution has to be treated as a security boundary rather than as a synchronization detail.

Before publishing a governed version, the system needs to reason about both sides of the boundary: what Commonset says the audience should be and what the provider will actually do with the artifact. If those scopes are incompatible, the correct result may be to prevent distribution, narrow the target, or require an explicit exception. Merely warning the administrator after publication is not enough when publication itself materially expands access.

This also explains why approval and deployment should remain separate. Security may approve a capability for a particular organizational use without deciding that it should immediately appear in every AI platform the company operates. One provider may preserve the intended audience correctly while another cannot. One integration may require broader credentials. One execution environment may introduce capabilities or risks that do not exist in the others.

An organizational trust decision can therefore remain stable while the distribution decision changes by provider.

The same distinction applies in reverse when provider state changes independently. If someone edits a provider copy directly, that remote state should not silently become the trusted organizational version. Commonset needs to be able to recognize drift, preserve the relationship between local and remote artifacts, and bring meaningful changes back into the governance workflow. Otherwise, the organization reviews one thing and eventually operates another.

This is also where provider credentials belong in the Security and IT conversation. A connected provider credential is a machine identity whose blast radius is defined partly by the external system. Commonset can encrypt the credential and authorize its use, but it cannot compensate for a token that has far more provider-side privilege than the integration needs. Credential scope, installation scope, and provider permissions are therefore part of the governance boundary, not merely configuration details.

The broader pattern is that every provider adds a second security model. Commonset should not pretend those models are identical. It should make the mismatch legible.

Governance should concentrate attention where it changes the outcome

Security teams have finite review capacity. That becomes important very quickly once AI capability creation is decentralized.

If every new prompt, workflow, or skill enters a manual security queue, one of two things will happen. The review process will become the bottleneck for AI adoption, or people will find ways around it. Neither outcome gives the security team better control.

The operating model needs to distinguish experimentation from organizational reliance.

A person exploring an approved model with public information does not require the same controls as a team sharing a reusable capability. A shared capability does not necessarily require the same process as an agent with production credentials. An agent that reads an internal system is different again from one that can modify records or initiate externally consequential actions. The governance burden should rise as the potential impact, privilege, sensitivity, audience, and organizational dependency rise.

Commonset's role in that model is to make the transitions explicit. A capability can exist without being approved for broad use. It can remain available to its creator while automated checks run. Ownership and provenance can be established before a security reviewer spends time on it. A team can use something under a defined scope before the organization decides it belongs in a wider Commonset. Explicit risk can still block use when the evidence warrants it.

This makes automation useful without making it authoritative. Deterministic checks can identify known problem classes, security findings can direct attention toward meaningful exceptions, and version comparison can help a reviewer focus on what actually changed. Human review can then be concentrated on the capabilities where judgment matters instead of being consumed by every artifact that enters the inventory.

The same principle should shape auditability. Security and IT eventually need to reconstruct important decisions: who changed a capability, what version was reviewed, why a warning was accepted, who approved broader distribution, when access changed, or why a particular provider received the artifact. The purpose of an audit trail is not simply to produce events. It is to preserve enough organizational context that a later reader can understand the decision.

For larger environments, some of those events will also need to participate in the customer's existing security operations. SIEM integration and security-event streaming are natural extensions of that requirement, but they do not replace in-product auditability. The people governing a capability should be able to understand its history in the same place they understand the capability itself. External security systems can then consume the events relevant to broader detection, response, and compliance workflows.

The outcome should be an operating model, not another security queue

I would approach an initial Commonset rollout with Security and IT by resisting the temptation to classify the entire organization immediately.

Connect a provider surface with a deliberately scoped credential and inspect what becomes visible. Identify which artifacts are already being reused rather than starting with every experiment. Establish ownership for the capabilities that matter. Look at provenance, version history, permissions, and existing distribution. Decide what evidence should be sufficient for low-risk team use and what characteristics should trigger deeper review. Create reviewer and manager boundaries that reflect actual responsibility rather than giving broad administrative privilege to everyone involved in AI.

Then observe where the model breaks.

You may discover that the same capability exists under several names. You may find that employees are already depending on an artifact nobody formally adopted. A provider may not support the audience restriction the organization needs. A capability may have been reviewed months ago but changed repeatedly since then. A warning may be harmless in one context and unacceptable in another. Those cases are more useful for developing policy than beginning with an abstract matrix of every conceivable AI risk.

Over time, Security and IT should be able to answer a relatively concrete set of questions about the capabilities the organization relies on: what do we have, who owns it, where did it come from, what changed, which exact revision did we review, what evidence informed that review, who is allowed to use it, which external systems can receive it, and whether the copies operating there still correspond to the version we intended.

Those questions are the operational core of AI capability governance.

They also expose why Commonset is not intended to become another approval portal. A portal can collect requests. The harder problem is maintaining the organizational state around reusable AI work after the request is closed. Capabilities continue changing. Providers change. Audiences expand. People leave. New implementations appear. The system needs to preserve identity and governance across that movement.

For Security and IT, the objective is not to make AI static enough to govern. It is to build a governance layer that remains useful while AI continues moving.

That means making unknown work visible without automatically criminalizing it, attaching trust to immutable versions, preserving provenance and ownership, keeping access separate from approval, treating provider distribution as its own security boundary, and escalating review when the actual risk justifies it.

If those controls work together, governance can increase organizational confidence without becoming the reason employees avoid the governed system in the first place.

That is the role Commonset is being built to play.