Skip to content

Trust and Security

Every marketplace package passes through multiple layers of security before it reaches your machine, and enforcement continues at runtime. This page covers how Ironspire signs, verifies, scores and sandboxes marketplace content.

Cryptographic signing

All marketplace packages are signed using Sigstore keyless signing. When an author publishes a package, Ironspire:

  1. Authenticates the author via their Ironspire account (linked to a verified email)
  2. Requests a short-lived signing certificate from the Sigstore certificate authority (Fulcio)
  3. Signs the package contents with the ephemeral key
  4. Records the signature in the Rekor transparency log, creating a tamper-evident, publicly auditable record

This approach eliminates the need for authors to manage long-lived signing keys. The transparency log means anyone can verify that a package was signed by a specific author at a specific time.

Verification on install

When you install a marketplace package, Ironspire automatically:

  • Downloads the package and its signature
  • Verifies the signature against the Rekor transparency log entry
  • Checks that the signing identity matches the listed author
  • Validates the SHA-256 content hash against the manifest

If any check fails, the installation is blocked and you see an error explaining which verification step failed.

Content integrity

Every file in a .isp package has a SHA-256 hash recorded in the manifest. These hashes are computed at publish time and verified at install time. If a single byte has been altered in transit or storage, the hash check fails and installation is blocked.

Versions are immutable once published. An author cannot silently modify a published version; they must publish a new version number. Combined with the transparency log, this gives you a complete, auditable chain of custody for every package on your system.

Permission manifest

Every package declares a PermissionManifest in its manifest.json that specifies exactly what the package needs access to. The schema defines five permission categories:

PermissionDescriptionExample
file_readRead access to the filesystem. Declares which paths or patterns the package may read.["./src/**", "./package.json"]
file_writeWrite access to the filesystem. Declares which paths or patterns the package may create or modify.["./dist/**"]
networkNetwork access. Lists allowed hosts or URL patterns.["api.github.com", "registry.npmjs.org"]
toolsClaude tools the package may invoke during agent sessions.["bash", "file_read", "web_search"]
mcp_serversOther MCP servers the package depends on or interacts with.["github-mcp", "filesystem"]

The permission manifest is displayed to users before installation so they can review exactly what a package requests. Overly broad permissions (e.g. unrestricted file_write or network access) increase the package's risk score.

Review the permission manifest before installing any package. A snippet or theme should never request network access or file_write permissions. If the permissions seem excessive for the content type, treat it as a red flag.

Risk scores

Ironspire calculates a risk score for every marketplace package based on its content type, declared permissions and security scan results. Scores are displayed on the package card and install dialog:

Risk levelIndicatorTypical triggers
LOWGreen shieldRead-only permissions, no network access, no executable code. Snippets, themes, prompt templates.
MEDIUMYellow shieldLimited file_write or network access, MCP server with scoped permissions. Configuration-level packages.
HIGHRed shieldBroad file_write, unrestricted network access, executable code, shell command access. MCP servers, hooks, workflows with wide permissions.

The risk score is informational; Ironspire does not block installation based on risk level alone. However, HIGH-risk packages trigger an additional confirmation dialog that requires you to acknowledge the risk before proceeding.

How scores are calculated

The scoring algorithm considers:

  • Content type weight: executable types (mcp_server, skill, hook) start with a higher base score than passive types (snippet, theme)
  • Permission breadth: wildcard paths, unrestricted network access and tool permissions increase the score
  • Security scan findings: warnings from the automated scanner add to the score
  • Author trust level: Official and Verified authors receive a small score reduction reflecting their established track record

Runtime enforcement

Permissions declared in the manifest are not just advisory; they are enforced at runtime. When an agent uses a marketplace package, Ironspire's runtime enforcement layer checks every action against the declared permissions:

  • File operations: read and write calls are validated against the declared file_read and file_write paths. Attempts to access undeclared paths are blocked.
  • Network requests: outbound connections are checked against the declared network hosts. Requests to undeclared hosts are blocked.
  • Tool invocations: tool calls are filtered through the canUseTool callback. Tools not listed in the manifest are unavailable to the package.
  • MCP server access: inter-server communication is restricted to the declared mcp_servers list.

Blocked actions are logged in Ironspire's activity monitor with the package name, the attempted action and the missing permission. This makes it straightforward to diagnose issues if a package is not working as expected due to missing permissions.

Sandbox tiers

Marketplace packages run in one of three sandbox tiers based on their content type and declared permissions:

Sandbox tierAccess levelContent types
PassiveRead-only. Can read files and display information but cannot modify anything.Snippets, themes, prompt templates
ConfigurationSettings access. Can read and write configuration files within defined scopes.Agent presets, project templates, collections
ExecutableCode execution. Can run commands, make network requests and modify files within declared permissions.MCP servers, skills, hooks, workflows

The sandbox tier is determined automatically from the package's content type and permissions. Authors cannot override it. Higher tiers receive stricter scrutiny during the publish review process.

Even in the Executable tier, packages are constrained by their declared permissions. A workflow with file_write: ["./reports/**"] can only write to the reports directory, regardless of its sandbox tier.

Kill switch

Ironspire maintains a mass recall capability for marketplace packages. If a security vulnerability is discovered in a published package, the Ironspire team can:

  1. Flag the package as compromised in the marketplace registry
  2. Push a recall notification to all installations
  3. Disable the package on affected machines until the author publishes a patched version

When a recall is triggered, affected users see a prominent notification explaining the issue and the recommended action (update or uninstall). The package's tools and capabilities are suspended immediately, but no user data is deleted.

This capability is reserved for genuine security incidents and is subject to the Ironspire team's security response process.

Tamper detection at rest

After installation, Ironspire periodically verifies installed package integrity by recomputing SHA-256 hashes and comparing them against the manifest. If a file has been modified on disk (whether by the user, another application or malware), Ironspire shows a warning and offers to reinstall the original version.

This check runs automatically on app launch and can be triggered manually from Marketplace > Installed > Verify Integrity.

Best practices for users

  • Check the trust level before installing. Official and Verified packages have undergone additional scrutiny.
  • Review permissions in the install dialog. Compare them against what the package claims to do.
  • Prefer LOW-risk packages when alternatives exist. A snippet achieves the same goal as a hook for many use cases, with far fewer permissions.
  • Keep packages updated. Security patches are delivered as new versions. Enable update notifications in settings.
  • Report suspicious packages via the flag icon on any package card. The Ironspire team reviews all reports.

Next steps