An employee creates a Claude project to save time on recurring work. They add instructions, upload reference material and connect a useful tool. Across a large enterprise, that pattern repeats until security has thousands of configurations to understand.
In September, Opsin ingested an enterprise environment with close to 11,000 Claude projects. That was roughly five times the average Claude environment we monitor.
A project count is a starting point. Projects differ in purpose, sharing, connected tools and activity. A project with reference documents has a different risk profile from a workflow that uses privileged credentials to interact with enterprise systems.
The security team needed to understand which projects carried meaningful risk, what their activity showed and where to intervene.
Most projects in this environment had no activity in the previous 30 days. A smaller group had no listed owner, and some retained connector access to enterprise data.
Inactivity alone does not establish that a project is safe to retire. It may support an infrequent business process. Missing ownership also makes review harder: someone must explain the purpose, confirm the access and approve changes.
These findings mattered, but orphan cleanup was not the customer’s first priority. Their main focus was on risk assessment and auditability.
The immediate questions were more specific:
One Claude project contained prompts and saved context with payroll and executive compensation details. The project was shared company-wide, making that content available beyond the restricted group permitted by company policy.
Sensitive information had already entered the project and become accessible to an overly broad audience. The finding established exposure, although it did not establish that an unauthorized employee had read the material.
Opsin classified the content as financial information and personally identifiable information, then combined those labels with the project's company-wide sharing scope. Together, those signals made the policy violation clear: restricted payroll content was available outside its permitted audience.
Opsin marked the project high priority and included the offending prompt or instruction in the alert. Auditors could then inspect the evidence behind the finding.
Opsin notified the owner and security stakeholders, recommended removing company-wide sharing and assigning a specific owner or service account, and generated a CSV/CMDB export for audit tracking and remediation ticketing.
This is the usage question security needs answered: what information was put into Claude, how was it handled and who could access it afterward?
Another project had an administrator credential embedded in its instructions or tool configuration. It also accepted external input through an email or webhook listener and could access sensitive datasets, including customer personal information or internal financial records.
Company policy prohibited configurations that allowed unauthenticated external input to trigger administrator-level actions on sensitive data. The combination created a path for untrusted instructions to influence privileged activity.
Opsin detected the embedded credential, inspected the tool's privileges and combined those findings with external-input capability and sensitive-data access. It classified the project as critical risk.
Opsin recommended immediate quarantine pending owner review and advised removing administrator privileges or narrowing connector scope. It also created an audit artifact documenting the relevant tool-call configuration and listener, and pushed an alert into the customer's security workflow.
Follow-up recommendations included rotating exposed credentials, removing external listeners or validating their inputs, and reassigning ownership.
Opsin also observed Microsoft 365 tool calls routed through a locally running MCP server rather than the approved gateway. MCP connects AI applications to external tools and data.
Those calls had occurred through an unapproved path, giving security activity evidence to investigate against its connection and change-management requirements.
Connecting that evidence to the right project was part of the work. Engineers triaged access errors and missing visibility, and improved connector-to-project attribution. Security needs that mapping to identify the responsible owner and recommend an appropriate change.
Opsin added CSV/CMDB exports to support audit and change management. Further work focused on a registry of risky Claude skills and governance for managed agents and MCP connectors. Runbooks were agreed next steps for helping auditors triage findings at scale.
At this scale, security needs a review order grounded in evidence.
This gives security a way to separate configuration concerns from observed activity requiring investigation. It also makes the next action clearer: validate the business need, notify an owner, narrow permissions or recommend quarantine.
The agreed rollout began with monitoring and risk assessment, followed by notifications and guided remediation. Runtime blocking was planned for a later phase, after confidence thresholds were met.
That sequencing reflected a practical concern: interrupting a useful workflow without understanding its dependencies can create its own business impact.
Retirement decisions follow the same logic. An ownerless, inactive project deserves review, but the organization should set the threshold, notice period and exception process. The inventory supplies the evidence needed to apply those decisions consistently.
Claude’s Compliance API provides activity events across Claude Enterprise and Claude Platform, with conversation, file and project content available for Claude Enterprise. The available evidence differs by deployment and endpoint.
This adds application-level evidence that endpoint or network records alone may not explain, including context for investigating how Claude is being used.
Opsin’s Compliance API integration brings that evidence into governance workflows. The API retrieves records after activity occurs, supporting investigation and response rather than inline blocking.
With 11,000 projects, the useful output is a prioritized set of findings tied to observed activity, business context and clear next steps. Opsin helps security explain what happened, why it matters under company policy, and what to do about it.
Yes. With the required content permissions, Opsin analyzes available project instructions and prompt content for embedded credentials and sensitive information, such as payroll details, personal information and financial records. It combines content sensitivity with sharing and access context to identify potential policy violations. When content access is restricted, Opsin can assess available metadata and connector signals, but visibility into sensitive content is limited.
Opsin inventories Claude projects and analyzes available metadata, sharing settings, instructions, tool-call configurations and associated connectors. Security teams can see who can access each project, what enterprise data it can reach and what available activity records show it has done. Opsin turns these signals into prioritized findings, including sensitive-data exposure, risky tool permissions and external-input configurations. Coverage depends on the permissions and data available to Opsin.
Opsin identifies risky combinations of external input, privileged tools and sensitive-data access. For example, a project that accepts external emails and uses administrator credentials to access financial records creates a path for untrusted instructions to influence privileged actions. Opsin correlates available project configurations, tool permissions and activity evidence to prioritize investigation. Finding this combination establishes a risk; it does not by itself prove that prompt injection or data exfiltration occurred.
Opsin needs read access to the project metadata, content and connector information relevant to the assessment. A proof of concept can begin with limited read permissions and expand as needed for sensitive-content inspection or more detailed activity attribution. Opsin provides a permissions checklist to help teams define the scope. Findings reflect the access granted, so restricted content permissions limit what Opsin can verify inside prompts and instructions.
Opsin provides prioritized findings, supporting prompt or tool-call evidence, explanations of the risk and CSV/CMDB exports for audit tracking. Recommended responses can include restricting project sharing, reducing connector privileges, rotating exposed credentials or quarantining a project pending review. Owner notifications and alerts routed into security workflows help teams track follow-up. Audit records should distinguish detected issues, recommended actions and confirmed remediation.
An employee creates a Claude project to save time on recurring work. They add instructions, upload reference material and connect a useful tool. Across a large enterprise, that pattern repeats until security has thousands of configurations to understand.
In September, Opsin ingested an enterprise environment with close to 11,000 Claude projects. That was roughly five times the average Claude environment we monitor.
A project count is a starting point. Projects differ in purpose, sharing, connected tools and activity. A project with reference documents has a different risk profile from a workflow that uses privileged credentials to interact with enterprise systems.
The security team needed to understand which projects carried meaningful risk, what their activity showed and where to intervene.
Most projects in this environment had no activity in the previous 30 days. A smaller group had no listed owner, and some retained connector access to enterprise data.
Inactivity alone does not establish that a project is safe to retire. It may support an infrequent business process. Missing ownership also makes review harder: someone must explain the purpose, confirm the access and approve changes.
These findings mattered, but orphan cleanup was not the customer’s first priority. Their main focus was on risk assessment and auditability.
The immediate questions were more specific:
One Claude project contained prompts and saved context with payroll and executive compensation details. The project was shared company-wide, making that content available beyond the restricted group permitted by company policy.
Sensitive information had already entered the project and become accessible to an overly broad audience. The finding established exposure, although it did not establish that an unauthorized employee had read the material.
Opsin classified the content as financial information and personally identifiable information, then combined those labels with the project's company-wide sharing scope. Together, those signals made the policy violation clear: restricted payroll content was available outside its permitted audience.
Opsin marked the project high priority and included the offending prompt or instruction in the alert. Auditors could then inspect the evidence behind the finding.
Opsin notified the owner and security stakeholders, recommended removing company-wide sharing and assigning a specific owner or service account, and generated a CSV/CMDB export for audit tracking and remediation ticketing.
This is the usage question security needs answered: what information was put into Claude, how was it handled and who could access it afterward?
Another project had an administrator credential embedded in its instructions or tool configuration. It also accepted external input through an email or webhook listener and could access sensitive datasets, including customer personal information or internal financial records.
Company policy prohibited configurations that allowed unauthenticated external input to trigger administrator-level actions on sensitive data. The combination created a path for untrusted instructions to influence privileged activity.
Opsin detected the embedded credential, inspected the tool's privileges and combined those findings with external-input capability and sensitive-data access. It classified the project as critical risk.
Opsin recommended immediate quarantine pending owner review and advised removing administrator privileges or narrowing connector scope. It also created an audit artifact documenting the relevant tool-call configuration and listener, and pushed an alert into the customer's security workflow.
Follow-up recommendations included rotating exposed credentials, removing external listeners or validating their inputs, and reassigning ownership.
Opsin also observed Microsoft 365 tool calls routed through a locally running MCP server rather than the approved gateway. MCP connects AI applications to external tools and data.
Those calls had occurred through an unapproved path, giving security activity evidence to investigate against its connection and change-management requirements.
Connecting that evidence to the right project was part of the work. Engineers triaged access errors and missing visibility, and improved connector-to-project attribution. Security needs that mapping to identify the responsible owner and recommend an appropriate change.
Opsin added CSV/CMDB exports to support audit and change management. Further work focused on a registry of risky Claude skills and governance for managed agents and MCP connectors. Runbooks were agreed next steps for helping auditors triage findings at scale.
At this scale, security needs a review order grounded in evidence.
This gives security a way to separate configuration concerns from observed activity requiring investigation. It also makes the next action clearer: validate the business need, notify an owner, narrow permissions or recommend quarantine.
The agreed rollout began with monitoring and risk assessment, followed by notifications and guided remediation. Runtime blocking was planned for a later phase, after confidence thresholds were met.
That sequencing reflected a practical concern: interrupting a useful workflow without understanding its dependencies can create its own business impact.
Retirement decisions follow the same logic. An ownerless, inactive project deserves review, but the organization should set the threshold, notice period and exception process. The inventory supplies the evidence needed to apply those decisions consistently.
Claude’s Compliance API provides activity events across Claude Enterprise and Claude Platform, with conversation, file and project content available for Claude Enterprise. The available evidence differs by deployment and endpoint.
This adds application-level evidence that endpoint or network records alone may not explain, including context for investigating how Claude is being used.
Opsin’s Compliance API integration brings that evidence into governance workflows. The API retrieves records after activity occurs, supporting investigation and response rather than inline blocking.
With 11,000 projects, the useful output is a prioritized set of findings tied to observed activity, business context and clear next steps. Opsin helps security explain what happened, why it matters under company policy, and what to do about it.
