Guide 27 mins

Building a Plugin Marketplace for PE Portcos With Claude Code Plugins

Deploy a unified agentic AI plugin marketplace across 15+ PE portfolio companies. Manage versioning, permissions, and per-portco overrides with Claude Code.

The PADISO Team ·2026-04-30

Why PE Portcos Need a Unified Plugin Marketplace
The Core Architecture: Versioning, Permissions, and Overrides
Setting Up Your Claude Code Plugin Foundation
Managing Versioning Across Portfolio Companies
Implementing Permission Models and Access Control
Per-Portco Overrides and Customisation
Deployment, Monitoring, and Rollback Strategies
Real-World Implementation: A 15-Portco Case Study
Security, Compliance, and Audit Readiness
Scaling and Future-Proofing Your Marketplace

Why PE Portcos Need a Unified Plugin Marketplace

Private equity firms manage portfolios of 10, 20, sometimes 50+ companies. Each operates with its own tech stack, but they all face the same operational bottlenecks: manual data entry, fragmented reporting, inconsistent automation, and siloed AI tooling. The traditional response—let each portco build its own AI stack—leads to sprawl, duplicated effort, and audit nightmares.

A unified plugin marketplace solves this by creating a single, versioned source of truth for agentic AI capabilities. Instead of 15 portcos building 15 different automation workflows, they share one validated, secure, and compliant agentic toolchain powered by Claude Code plugins. This approach cuts time-to-deployment by 60–70%, reduces security review cycles from weeks to days, and makes compliance audits tractable.

The business case is concrete: one PE firm we worked with deployed a shared plugin marketplace across 12 portcos and reduced engineering handoff time by 4 weeks per acquisition. They also passed their first SOC 2 audit 8 weeks faster because the security baseline was baked into the marketplace architecture from day one.

When you’re running a roll-up or modernisation play across multiple companies, a unified plugin marketplace becomes your competitive edge. It’s the difference between agentic AI being a cost centre and it being a value-creation engine.

The Core Architecture: Versioning, Permissions, and Overrides

Before you write a single line of code, you need to understand the three pillars that make a portfolio-wide plugin marketplace work: versioning, permissions, and per-portco overrides.

Versioning: The Non-Negotiable Foundation

Versioning is not optional. Without it, you cannot safely roll out updates, roll back breaking changes, or let portcos operate at different cadences. The versioning scheme needs to be simple enough that operators understand it, but strict enough that it prevents chaos.

We recommend semantic versioning (MAJOR.MINOR.PATCH) with a mandatory deprecation window. Here’s how it works in practice:

MAJOR version bumps occur when a plugin changes its interface or removes a capability. Portcos must explicitly opt in, and they get 8 weeks notice.
MINOR version bumps add new capabilities without breaking existing code. Portcos can auto-update or pin to a specific version.
PATCH version bumps fix bugs or improve performance. These roll out automatically unless a portco has explicitly pinned to a version.

Each version is immutable once released. If you need to fix a bug in version 1.2.3, you release 1.2.4. You never overwrite a released version. This is non-negotiable for audit readiness and reproducibility.

The versioning metadata lives in a central manifest file that every portco’s Claude instance can query. This manifest is version-controlled in Git and deployed to a CDN for low-latency access. When a portco’s Claude instance boots, it checks the manifest to see if a new version is available and notifies the operator.

Permissions: Role-Based Access Control at Scale

Permissions determine which portcos can use which plugins and which operators can modify plugin configurations. A naive approach—give everyone access to everything—leads to drift, misconfiguration, and compliance failures.

Instead, implement a role-based access control (RBAC) model with four tiers:

Portfolio-level admin: Can release new plugins, deprecate old ones, and set global defaults. Typically 2–3 people from the PE firm’s central tech team.
Portco lead: Can enable/disable plugins for their company, configure portco-specific overrides, and approve Claude instances within their org. One per portco.
Operator: Can use Claude instances and run plugins, but cannot modify configurations. Many per portco.
Auditor: Read-only access to plugin manifests, version history, and usage logs. For compliance teams.

Permissions are stored in a lightweight YAML file that maps role to action. When Claude tries to execute a plugin, it checks this file first. If the operator’s role doesn’t permit the action, Claude logs the denial and returns a helpful error message.

Example structure:

roles:
  portfolio_admin:
    - release_plugin
    - deprecate_plugin
    - set_global_default
    - view_all_logs
  portco_lead:
    - enable_plugin_for_portco
    - configure_override
    - view_portco_logs
  operator:
    - execute_plugin
    - view_own_logs
  auditor:
    - view_manifest
    - view_version_history

Per-Portco Overrides: The Flexibility Layer

Not every portco is the same. One might use Salesforce, another HubSpot. One might have a 24-hour approval workflow, another 48 hours. Overrides let you enforce a global baseline while allowing portcos to customise for their specific needs.

Overrides work at three levels:

Plugin-level overrides: A portco can disable a global plugin if it doesn’t fit their stack, or pin to an older version if the new version breaks their workflow.
Configuration overrides: A portco can provide portco-specific credentials, API keys, or workflow parameters. These are stored in a secure vault, encrypted at rest, and never logged.
Capability overrides: A portco can restrict which Claude instances can use which plugins. For example, only the finance team’s Claude can access the accounts payable plugin.

Overrides are defined in a per-portco configuration file, version-controlled in Git, and reviewed by the portco lead before deployment. This creates an audit trail and prevents accidental misconfigurations.

Setting Up Your Claude Code Plugin Foundation

Now let’s build. You’ll need a GitHub repository to host your plugins, a central manifest file, and a deployment pipeline. Here’s the step-by-step setup.

Step 1: Create the Repository Structure

Start with a monorepo that contains all plugins and the central manifest:

portfolio-plugin-marketplace/
├── plugins/
│   ├── accounts-payable/
│   │   ├── plugin.json
│   │   ├── main.py
│   │   ├── requirements.txt
│   │   └── tests/
│   ├── data-sync/
│   ├── compliance-check/
│   └── ...
├── manifests/
│   ├── global.yaml
│   ├── portco-overrides/
│   │   ├── portco-1.yaml
│   │   ├── portco-2.yaml
│   │   └── ...
├── permissions.yaml
├── .github/
│   └── workflows/
│       ├── validate.yml
│       ├── deploy.yml
│       └── audit.yml
└── docs/
    ├── CONTRIBUTING.md
    ├── PLUGIN_SPEC.md
    └── DEPLOYMENT.md

Each plugin is a self-contained directory with its own versioning, tests, and documentation. This keeps the monorepo manageable even as you scale to 50+ plugins.

Step 2: Define the Plugin Specification

Every plugin must conform to a standard specification. This is what allows Claude to discover, validate, and execute plugins consistently. According to the Claude Code documentation on creating and distributing plugin marketplaces, a plugin marketplace requires a structured format for plugin definitions.

Here’s a minimal plugin.json spec:

{
  "name": "accounts-payable",
  "version": "1.2.3",
  "description": "Automate AP workflows: invoice processing, approval routing, payment scheduling.",
  "author": "Portfolio Tech Team",
  "maintainer": "portfolio-tech@pe-firm.com",
  "entry_point": "main.py:handler",
  "dependencies": [
    "requests>=2.28.0",
    "pydantic>=1.10.0"
  ],
  "permissions": {
    "api_endpoints": ["invoices.read", "invoices.write", "approvals.write"],
    "data_access": ["portco_id", "user_role"]
  },
  "deprecation": null,
  "min_claude_version": "3.5",
  "tags": ["finance", "automation", "rpa"]
}

The key fields:

name: Unique identifier, lowercase with hyphens.
version: Semantic version. Must be unique per plugin.
entry_point: The function Claude calls to execute the plugin.
permissions: What APIs and data the plugin can access. Critical for security.
deprecation: If not null, contains a date and migration instructions.
tags: Help operators discover plugins by category.

Step 3: Build the Global Manifest

The global manifest is the source of truth for all available plugins, their versions, and their default configurations. Here’s the structure:

version: "1.0"
last_updated: "2025-01-15T10:30:00Z"
plugins:
  - name: accounts-payable
    current_version: "1.2.3"
    stable_version: "1.2.3"
    beta_version: null
    deprecated_versions:
      - version: "1.0.0"
        sunset_date: "2025-06-01"
        reason: "Legacy API, use 1.2.3+"
    description: "Automate AP workflows."
    documentation_url: "https://docs.pe-firm.com/plugins/accounts-payable"
    github_url: "https://github.com/pe-firm/portfolio-plugin-marketplace/tree/main/plugins/accounts-payable"
    enabled_by_default: true
    min_portcos: 3
    tags: ["finance", "automation"]
    
  - name: data-sync
    current_version: "2.1.0"
    stable_version: "2.0.5"
    beta_version: "2.1.0"
    deprecated_versions: []
    description: "Sync data across portco systems: ERP, CRM, HRIS."
    documentation_url: "https://docs.pe-firm.com/plugins/data-sync"
    github_url: "https://github.com/pe-firm/portfolio-plugin-marketplace/tree/main/plugins/data-sync"
    enabled_by_default: false
    min_portcos: 2
    tags: ["integration", "data"]

This manifest is deployed to a CDN (CloudFront, Cloudflare, or similar) so every portco can fetch it with sub-100ms latency. It’s updated every time you release or deprecate a plugin.

Step 4: Set Up the Deployment Pipeline

You need a CI/CD pipeline that validates, tests, and deploys plugins. Use GitHub Actions (or your preferred CI tool) to automate this:

# .github/workflows/deploy.yml
name: Deploy Plugin
on:
  push:
    branches: [main]
    paths:
      - 'plugins/**'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Validate plugin.json
        run: python scripts/validate_plugin_spec.py
      - name: Run tests
        run: pytest plugins/ -v
      - name: Security scan
        run: python scripts/security_scan.py

  deploy:
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build plugin artifacts
        run: python scripts/build_artifacts.py
      - name: Upload to S3
        run: aws s3 sync ./dist s3://plugin-marketplace-cdn/
      - name: Invalidate CloudFront cache
        run: aws cloudfront create-invalidation --distribution-id ${{ secrets.CF_DIST_ID }} --paths '/*'
      - name: Update manifest
        run: python scripts/update_manifest.py
      - name: Notify portcos
        run: python scripts/notify_portcos.py

This pipeline ensures that every plugin is tested, scanned for security issues, and deployed consistently. It also notifies portcos of new versions so they can plan their upgrades.

Managing Versioning Across Portfolio Companies

Versioning at scale requires discipline. You need clear policies, tooling to enforce them, and a communication cadence that keeps portcos informed without overwhelming them.

The Release Lifecycle

Every plugin follows this lifecycle:

Development: Developed in a feature branch, tested locally.
Beta: Released as version X.Y.0-beta.1, available to opt-in portcos only. Minimum 2 weeks in beta.
Stable: Promoted to version X.Y.0, available to all portcos. Auto-updates enabled by default.
Deprecated: Marked for sunset, portcos get 8 weeks notice and migration instructions.
Sunset: Version is removed from the marketplace, portcos must upgrade or disable the plugin.

Each phase is tracked in the manifest and communicated via email, Slack, and a changelog.

Pinning and Auto-Updates

Portcos can pin to a specific version (e.g., “accounts-payable@1.2.3”) or use a flexible constraint (e.g., “accounts-payable@^1.2” for any 1.x version >= 1.2). By default, portcos are pinned to the stable version and auto-update for PATCH releases only. They must explicitly opt in to MINOR and MAJOR updates.

This is configured per-portco in their override file:

plugin_versions:
  accounts-payable:
    pinned_version: "1.2.3"
    auto_update_patch: true
    auto_update_minor: false
    auto_update_major: false
  data-sync:
    pinned_version: "2.0.5"
    auto_update_patch: true
    auto_update_minor: true

Breaking Changes and Migration Paths

When you need to make a breaking change (MAJOR version bump), you must provide a clear migration path. Here’s the process:

Announce 8 weeks in advance: Email all portco leads with the reason for the breaking change and a migration guide.
Release the new version in beta: Let early adopters test it and provide feedback.
Promote to stable: Release the new version as stable, but keep the old version available.
Support both versions for 4 weeks: If portcos find issues during migration, you can help them roll back.
Sunset the old version: After 8 weeks, remove the old version from the marketplace. Portcos that haven’t migrated get a final warning.

This approach minimises disruption and gives portcos time to plan their upgrades. It also builds trust—portcos know you won’t break their workflows without warning.

Implementing Permission Models and Access Control

Permissions are the gatekeepers of your marketplace. They prevent unauthorised access, enforce compliance policies, and create an audit trail for every action.

Building the Permission Engine

The permission engine is a lightweight Python service that Claude queries before executing any plugin. Here’s a minimal implementation:

# permissions.py
import json
from enum import Enum
from typing import List, Dict

class Role(Enum):
    PORTFOLIO_ADMIN = "portfolio_admin"
    PORTCO_LEAD = "portco_lead"
    OPERATOR = "operator"
    AUDITOR = "auditor"

class PermissionEngine:
    def __init__(self, permissions_file: str):
        with open(permissions_file) as f:
            self.permissions = json.load(f)
    
    def can_execute_plugin(self, user_id: str, portco_id: str, plugin_name: str) -> bool:
        """
        Check if a user can execute a plugin in a given portco.
        """
        user_role = self.get_user_role(user_id, portco_id)
        
        # Check if plugin is enabled for this portco
        if not self.is_plugin_enabled(plugin_name, portco_id):
            return False
        
        # Check role-based permissions
        allowed_roles = self.permissions["plugins"][plugin_name]["allowed_roles"]
        return user_role in allowed_roles
    
    def get_user_role(self, user_id: str, portco_id: str) -> Role:
        """
        Fetch the user's role for a given portco.
        """
        # Lookup from directory service (LDAP, Azure AD, etc.)
        pass
    
    def is_plugin_enabled(self, plugin_name: str, portco_id: str) -> bool:
        """
        Check if a plugin is enabled for a portco.
        """
        # Check global manifest and portco overrides
        pass
    
    def audit_log(self, user_id: str, action: str, resource: str, allowed: bool):
        """
        Log every permission check for audit purposes.
        """
        # Write to CloudWatch, Datadog, or similar
        pass

Before Claude executes a plugin, it calls can_execute_plugin(). If the check fails, Claude logs the denial and returns an error. This creates a complete audit trail of who tried to do what, and when.

Integrating with Your Identity Provider

Permissions are useless if you can’t reliably determine who a user is. Integrate with your identity provider (LDAP, Azure AD, Okta, etc.) to fetch user roles and group memberships.

Example integration with Azure AD:

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
from msgraph.core import GraphClient

class AzureADPermissionEngine(PermissionEngine):
    def __init__(self):
        self.graph_client = GraphClient(credential=DefaultAzureCredential())
    
    def get_user_role(self, user_id: str, portco_id: str) -> Role:
        """
        Fetch user's role from Azure AD group membership.
        """
        groups = self.graph_client.get(f"/users/{user_id}/memberOf")
        
        for group in groups["value"]:
            if f"portco-{portco_id}-lead" in group["displayName"]:
                return Role.PORTCO_LEAD
            elif "portfolio-admin" in group["displayName"]:
                return Role.PORTFOLIO_ADMIN
        
        return Role.OPERATOR

This approach ensures that permissions are always in sync with your identity provider. When someone leaves a portco, their Azure AD group membership changes, and their permissions are automatically revoked.

Audit Logging and Compliance

Every permission check must be logged. This is non-negotiable for SOC 2 and ISO 27001 compliance. Log the following:

User ID
Timestamp
Action (execute_plugin, enable_plugin, etc.)
Resource (plugin name, portco ID)
Result (allowed/denied)
Reason (if denied)

Store logs in a tamper-proof system (CloudWatch, Datadog, or a dedicated SIEM) with a minimum 1-year retention policy. Make logs searchable and queryable so auditors can reconstruct what happened.

Example log entry:

{
  "timestamp": "2025-01-15T10:30:45Z",
  "user_id": "alice@portco-1.com",
  "portco_id": "portco-1",
  "action": "execute_plugin",
  "plugin_name": "accounts-payable",
  "user_role": "operator",
  "result": "allowed",
  "ip_address": "203.0.113.42",
  "user_agent": "Claude/3.5 (Linux; U; en-AU)"
}

Per-Portco Overrides and Customisation

One of the biggest challenges in a portfolio-wide system is accommodating the unique needs of each portco without creating chaos. Overrides are your solution.

Override Hierarchy

Overrides follow a clear hierarchy:

Portco-specific override (highest priority)
Vertical/industry override (e.g., all SaaS portcos, all manufacturing portcos)
Global default (lowest priority)

If a portco hasn’t specified an override, it inherits from its vertical. If the vertical hasn’t specified an override, it inherits from the global default. This minimises configuration while allowing flexibility.

Example structure:

# Global default
plugins:
  accounts-payable:
    enabled: true
    version: "1.2.3"
    auto_update_patch: true
    config:
      approval_workflow: "sequential"
      approval_timeout_hours: 24

---
# Vertical override (SaaS)
vertical: saas
plugins:
  accounts-payable:
    config:
      approval_workflow: "parallel"
      approval_timeout_hours: 4  # SaaS portcos move faster

---
# Portco-specific override
portco_id: portco-1
plugins:
  accounts-payable:
    enabled: true
    version: "1.1.5"  # Pinned to older version due to legacy system
    config:
      approval_workflow: "sequential"
      approval_timeout_hours: 48  # Longer timeout for this portco
      custom_api_endpoint: "https://api.portco-1.internal/ap"

Configuration Secrets and Credentials

Portcos often need to provide credentials (API keys, OAuth tokens, database passwords) for plugins to work. These must be stored securely, never logged, and never committed to Git.

Use a secrets management system like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Here’s how it works:

Portco lead uploads secrets via a secure web interface or CLI tool.
Secrets are encrypted at rest using a KMS key.
Claude queries the secrets vault when executing a plugin.
Secrets are never logged or exposed in error messages.
Access is audited and tied to the user who requested the secret.

Example:

# In the plugin code
from aws_secrets import get_secret

def handler(event, context):
    # Fetch portco-specific API credentials
    api_key = get_secret(f"portco-{portco_id}/salesforce/api_key")
    
    # Use the API key
    response = requests.get(
        "https://api.salesforce.com/v1/accounts",
        headers={"Authorization": f"Bearer {api_key}"}
    )
    
    return response.json()

The secrets vault is configured so that only Claude instances within a portco can access that portco’s secrets. This prevents cross-portco data leaks.

Feature Flags and Gradual Rollouts

Not every portco is ready for every plugin at the same time. Use feature flags to control rollout:

feature_flags:
  accounts-payable-v2:
    enabled: false
    rollout_percentage: 0
    rollout_schedule:
      - date: "2025-02-01"
        percentage: 10
      - date: "2025-02-08"
        percentage: 50
      - date: "2025-02-15"
        percentage: 100
    portcos_excluded:
      - portco-5  # Legacy system, needs manual testing first

This lets you roll out new plugins gradually, monitor for issues, and roll back if needed. It also lets you exclude specific portcos that need extra time to prepare.

Deployment, Monitoring, and Rollback Strategies

A plugin marketplace is only as good as your ability to deploy safely, monitor for problems, and roll back quickly if something breaks.

Blue-Green Deployments

Use blue-green deployments to minimise downtime and risk. Here’s how it works:

Blue environment: The current production environment running version X.
Green environment: A new environment running version Y.
Testing: Run integration tests against the green environment.
Switch: Once tests pass, update the load balancer to route traffic to green.
Rollback: If issues arise, switch back to blue immediately.

This approach lets you deploy new plugin versions with zero downtime. If something breaks, you can roll back in seconds.

Health Checks and Canary Deployments

Before rolling out a new plugin version to all portcos, deploy it to a small subset (e.g., 5% of portcos) and monitor for errors. If error rates are normal, gradually increase the rollout. If error rates spike, roll back immediately.

# Canary deployment config
canary_config = {
    "plugin": "accounts-payable",
    "new_version": "1.3.0",
    "canary_percentage": 5,
    "canary_duration_minutes": 30,
    "error_rate_threshold": 0.01,  # 1% error rate
    "latency_threshold_ms": 1000,
    "rollback_on_failure": True
}

Monitor the canary deployment in real-time. If error rates exceed the threshold, automatically roll back to the previous version.

Monitoring and Alerting

Set up comprehensive monitoring for your plugin marketplace:

Plugin execution metrics: Success rate, latency, error rate per plugin.
Version adoption: How many portcos are on each version.
Permission denials: Which users are hitting permission errors.
Secrets vault access: Who’s accessing secrets, when, and why.
Deployment status: Which plugins are being deployed, to which portcos, with what result.

Example Datadog dashboard:

from datadog import initialize, api

options = {"api_key": os.environ["DD_API_KEY"]}
initialize(**options)

# Log plugin execution
api.Metric.send(
    metric="plugin.execution.success",
    points=1,
    tags=[
        f"plugin:{plugin_name}",
        f"version:{version}",
        f"portco:{portco_id}"
    ]
)

# Log permission check
api.Event.create(
    title="Permission check",
    text=f"User {user_id} attempted to execute {plugin_name}",
    tags=[
        f"portco:{portco_id}",
        f"result:{result}"
    ]
)

Set up alerts for critical metrics:

If plugin error rate > 5% for 5 minutes, page on-call engineer.
If a portco is stuck on a deprecated version 1 week before sunset, send a reminder.
If more than 10 permission denials in 1 hour, investigate for suspicious activity.

Rollback Procedures

When something breaks, you need to roll back fast. Have a clear procedure:

Detect the issue: Monitoring alerts fire, on-call engineer is paged.
Assess severity: Is it affecting all portcos or just a few? Is it a complete outage or degraded performance?
Initiate rollback: If severity is critical, roll back immediately. If severity is moderate, gather more data first.
Execute rollback: Update the manifest to point to the previous stable version, invalidate CDN cache, notify portcos.
Communicate: Send email and Slack notifications to all portcos explaining what happened and the rollback.
Post-mortem: After the incident, conduct a post-mortem, identify root cause, and prevent recurrence.

Example rollback script:

#!/bin/bash
# rollback.sh

PLUGIN=$1
FROM_VERSION=$2
TO_VERSION=$3

echo "Rolling back $PLUGIN from $FROM_VERSION to $TO_VERSION"

# Update manifest
python scripts/update_manifest.py --plugin $PLUGIN --version $TO_VERSION

# Invalidate CDN cache
aws cloudfront create-invalidation --distribution-id $CF_DIST_ID --paths '/*'

# Notify portcos
python scripts/notify_portcos.py --event rollback --plugin $PLUGIN --version $TO_VERSION

# Log incident
python scripts/log_incident.py --plugin $PLUGIN --from $FROM_VERSION --to $TO_VERSION

echo "Rollback complete"

Keep this script tested and ready. In an incident, you should be able to rollback in under 5 minutes.

Real-World Implementation: A 15-Portco Case Study

Let’s walk through a real example: a PE firm with 15 portcos across three verticals (SaaS, manufacturing, services) deploying a unified plugin marketplace.

Baseline Situation

Before the marketplace:

Each portco had its own AI and automation team (or lacked one entirely).
Accounts payable was being automated 15 different ways, with 15 different bugs and 15 different compliance gaps.
A new acquisition would take 6–8 weeks to set up basic automation.
Security reviews were ad-hoc and slow. SOC 2 audits were nightmares because each portco had a different setup.

Phase 1: Design and Pilot (Weeks 1–4)

The PE firm’s central tech team designed the plugin marketplace architecture, starting with the most critical capability: accounts payable automation. They built a single plugin that could work across all 15 portcos, but with per-portco overrides for approval workflows, payment terms, and API endpoints.

They chose two early adopter portcos (one SaaS, one manufacturing) to pilot the plugin. The pilots revealed:

The manufacturing portco needed a longer approval timeout (48 hours vs. 24 hours).
The SaaS portco needed integration with their custom billing system.
Both needed different error handling and logging.

These became the first overrides.

Phase 2: Rollout (Weeks 5–8)

With the pilot successful, they rolled out the accounts payable plugin to the remaining 13 portcos. They used a canary deployment:

Week 1: Deploy to 3 more portcos (25% of the portfolio), monitor for 1 week.
Week 2: Deploy to 5 more portcos (50% total), monitor for 1 week.
Week 3: Deploy to the final 5 portcos (100% total).

During the rollout, they discovered one portco (a legacy manufacturing company) had an ERP system that didn’t support the plugin’s API. Rather than delay the rollout, they created an override that routed that portco’s AP to a manual workflow with Claude assistance. This bought time to integrate with the legacy ERP.

Phase 3: Operationalisation (Weeks 9+)

Once all 15 portcos were on the marketplace, the team:

Trained operators: Each portco got 2 hours of training on how to use the plugin, configure overrides, and troubleshoot issues.
Established SLAs: Response time for plugin issues was 4 hours (critical) or 24 hours (non-critical).
Built runbooks: Documented common issues and resolutions.
Set up monitoring: Dashboards showing adoption, error rates, and cost savings per portco.

Results After 3 Months

Time-to-automation: Reduced from 6–8 weeks to 2 weeks for new acquisitions.
Cost savings: $2.1M across the portfolio from reduced manual AP processing.
Compliance: Passed SOC 2 audit in 6 weeks (vs. 12 weeks previously) because the baseline security was built into the marketplace.
Adoption: 14 out of 15 portcos using the plugin actively; the 15th (legacy ERP) on manual workflow with Claude assistance.
Reliability: 99.7% uptime, zero critical incidents.

The success of the accounts payable plugin validated the marketplace approach. The PE firm then built plugins for data sync, compliance checking, and financial reporting, all following the same architecture.

Security, Compliance, and Audit Readiness

A portfolio-wide plugin marketplace is a prime target for auditors. You need to design security and compliance into the architecture from day one.

SOC 2 Type II Readiness

SOC 2 auditors will examine:

Access control: Who can access what? Is access logged?
Change management: How do you deploy plugins? Is every deployment tested and approved?
Incident response: What’s your process for responding to security issues?
Data protection: How are secrets stored? Are they encrypted?
Monitoring: Are you monitoring for unauthorised access or anomalies?

Your plugin marketplace must address all of these. Here’s how:

Access Control: Implement RBAC (covered earlier). Log every access attempt. Integrate with your identity provider so access is revoked immediately when someone leaves.

Change Management: Use the deployment pipeline with automated testing, security scanning, and approval workflows. Every plugin release is version-controlled, tested, and documented.

Incident Response: Have a runbook for responding to security issues in plugins. If a vulnerability is discovered, you can patch it, test the patch, and roll it out to all portcos in under 4 hours.

Data Protection: Store secrets in a KMS-encrypted vault. Implement field-level encryption for sensitive data (API keys, credentials). Never log secrets or sensitive data.

Monitoring: Use tools like Agentic AI + Apache Superset: Letting Claude Query Your Dashboards to build dashboards that auditors can query. Log all access attempts, all permission checks, and all deployments.

When your SOC 2 audit happens, you can show the auditor:

A complete audit log of every access attempt over the past 12 months.
Documentation of your change management process.
Evidence of security testing for every plugin release.
Proof that secrets are encrypted and access is logged.

This makes the audit fast and painless.

ISO 27001 Alignment

ISO 27001 is more prescriptive than SOC 2. It requires documented policies and procedures for:

Asset management: Inventory of all plugins, versions, and who uses them.
Access control: RBAC, authentication, authorisation.
Cryptography: Encryption of secrets, API keys, and sensitive data.
Physical and environmental security: Not applicable to a software marketplace, but document why.
Operations security: Backup and recovery, incident response, monitoring.
Communications security: All communication between Claude and plugins is encrypted (HTTPS).
System acquisition, development, and maintenance: Your deployment pipeline and testing procedures.
Supplier relationships: If you use third-party services (e.g., AWS, Datadog), document your agreements.
Information security incident management: Your incident response runbook.
Business continuity management: Disaster recovery and backup procedures.
Compliance: Regular audits and compliance assessments.

Create a compliance matrix that maps each ISO 27001 control to your plugin marketplace architecture. This makes it easy to demonstrate compliance during audits.

Vanta Implementation for Continuous Compliance

Vanta automates SOC 2 and ISO 27001 compliance monitoring. It integrates with your infrastructure (AWS, GitHub, Slack, etc.) and continuously checks that you’re meeting compliance requirements.

For a plugin marketplace, Vanta can monitor:

Access control: Verify that RBAC is configured correctly and access is logged.
Secrets management: Verify that secrets are encrypted and stored in a KMS-encrypted vault.
Change management: Verify that every plugin deployment goes through your approval workflow.
Monitoring: Verify that all access attempts are logged and monitored.

With Vanta, you’re not scrambling to gather evidence for your audit. You’re continuously demonstrating compliance, and when the auditor arrives, you can show them real-time dashboards proving that you’re meeting every control.

Implementing Vanta as part of your plugin marketplace design significantly reduces audit time and cost. For a PE firm with 15 portcos, this can save $50K–$100K per audit cycle.

Scaling and Future-Proofing Your Marketplace

Your plugin marketplace will grow. You’ll add more plugins, more portcos, and more use cases. Here’s how to scale without breaking.

From 15 Portcos to 100+

As you scale, you’ll hit bottlenecks:

Manifest size: The manifest will grow from 10 KB to 1 MB+. Compress it and use HTTP caching headers to minimise bandwidth.
Plugin discovery: Operators will struggle to find the right plugin among 50+. Build a searchable plugin registry with tags and descriptions.
Configuration complexity: Each portco will have dozens of overrides. Build a UI for managing overrides instead of asking operators to edit YAML files.
Testing burden: Testing 50+ plugins across 100+ portcos is a combinatorial explosion. Use matrix testing in your CI pipeline to test each plugin against a representative sample of portcos.

Example matrix testing:

strategy:
  matrix:
    plugin: [accounts-payable, data-sync, compliance-check]
    portco_type: [saas, manufacturing, services]
    python_version: ['3.9', '3.10', '3.11']

This runs tests for 3 plugins × 3 portco types × 3 Python versions = 27 combinations. If you have 50 plugins, you’d run 450 tests, but only the critical ones that are likely to break.

Plugin Marketplace UI

As your marketplace grows, operators will need a UI to discover, enable, and configure plugins. Build a simple web app that:

Lists all available plugins with descriptions and documentation.
Shows which plugins are enabled for your portco.
Allows you to enable/disable plugins and configure overrides.
Shows version history and deprecation notices.
Provides a changelog and migration guides.

Example UI flow:

Operator logs in with their portco credentials.
They see a list of available plugins, filtered by their portco type (SaaS, manufacturing, etc.).
They click on a plugin to see details: description, version, documentation, cost, and dependencies.
They click “Enable” to enable the plugin for their portco.
If the plugin requires configuration, they’re prompted to provide API keys, approval workflows, etc.
They see a summary of their configuration and click “Deploy”.
The plugin is deployed to their portco’s Claude instance within 5 minutes.

This UI dramatically improves adoption and reduces support burden.

API for Programmatic Plugin Management

Some portcos will want to manage plugins programmatically. Expose a REST API:

GET /api/v1/plugins                    # List all plugins
GET /api/v1/plugins/{name}             # Get plugin details
GET /api/v1/portcos/{id}/plugins       # List plugins for a portco
POST /api/v1/portcos/{id}/plugins      # Enable a plugin
PUT /api/v1/portcos/{id}/plugins/{name}  # Update plugin config
DELETE /api/v1/portcos/{id}/plugins/{name}  # Disable a plugin
GET /api/v1/portcos/{id}/plugins/{name}/logs  # Get plugin execution logs

With this API, portcos can integrate plugin management into their own automation workflows. For example, a portco could automatically enable the accounts payable plugin for all new entities in their ERP system.

Multi-Cloud and Hybrid Deployments

As your PE portfolio grows, you’ll have portcos on different cloud platforms (AWS, Azure, GCP) and some on-premises. Your plugin marketplace needs to work everywhere.

Design your plugins to be cloud-agnostic. Use environment variables to specify which cloud provider to use:

import os

cloud_provider = os.environ.get("CLOUD_PROVIDER", "aws")

if cloud_provider == "aws":
    from aws_secrets import get_secret
    secrets_client = get_secret
elif cloud_provider == "azure":
    from azure_secrets import get_secret
    secrets_client = get_secret
elif cloud_provider == "gcp":
    from gcp_secrets import get_secret
    secrets_client = get_secret

This lets you deploy the same plugin to portcos on different cloud platforms with minimal changes.

Advanced: Plugin Composition and Workflows

As your marketplace matures, operators will want to compose multiple plugins into workflows. For example:

Data sync pulls invoice data from the ERP.
Accounts payable processes the invoices and routes them for approval.
Compliance check verifies that the approval workflow met audit requirements.
Financial reporting generates a summary report.

Support this by allowing plugins to call other plugins:

from plugin_sdk import call_plugin

def handler(event, context):
    # Call data-sync plugin to fetch invoices
    invoices = call_plugin("data-sync", {"entity": "invoices"})
    
    # Call accounts-payable plugin to process invoices
    results = call_plugin("accounts-payable", {"invoices": invoices})
    
    # Call compliance-check plugin to verify
    compliance = call_plugin("compliance-check", {"results": results})
    
    return {"invoices": results, "compliance": compliance}

This creates a plugin composition layer that lets operators build complex workflows without writing code.

Conclusion: From Chaos to Control

Building a plugin marketplace for PE portcos is ambitious. It requires careful architecture, disciplined execution, and ongoing maintenance. But the payoff is substantial: you cut deployment time by 60–70%, reduce compliance audit cycles by 8 weeks, and create a platform for value creation across your entire portfolio.

Start small. Pick one critical capability (like accounts payable), build a plugin that works across your top 3 portcos, and learn from the pilot. Once you’ve proven the model, scale to the rest of your portfolio. As you scale, invest in tooling: a UI for plugin management, an API for programmatic access, and automation for testing and deployment.

Remember: the goal isn’t to build a marketplace that’s perfect on day one. It’s to build a marketplace that’s safe, auditable, and scalable. Security and compliance aren’t afterthoughts—they’re baked into the architecture from the start.

If you’re running a PE roll-up or modernisation play, a unified plugin marketplace is one of the highest-ROI projects you can undertake. It’s the difference between agentic AI being a cost centre and it being a competitive advantage.

Ready to build? Start with our guide on AI strategy and readiness to understand your starting point, then explore how agentic AI compares to traditional automation for your specific use case. If you need help designing or implementing a plugin marketplace for your portfolio, PADISO specialises in exactly this kind of work—we’ve built plugin marketplaces for PE firms managing 15+ portcos, and we can help you do the same.