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:
- Authenticates the author via their Ironspire account (linked to a verified email)
- Requests a short-lived signing certificate from the Sigstore certificate authority (Fulcio)
- Signs the package contents with the ephemeral key
- 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:
| Permission | Description | Example |
|---|---|---|
| file_read | Read access to the filesystem. Declares which paths or patterns the package may read. | ["./src/**", "./package.json"] |
| file_write | Write access to the filesystem. Declares which paths or patterns the package may create or modify. | ["./dist/**"] |
| network | Network access. Lists allowed hosts or URL patterns. | ["api.github.com", "registry.npmjs.org"] |
| tools | Claude tools the package may invoke during agent sessions. | ["bash", "file_read", "web_search"] |
| mcp_servers | Other 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 level | Indicator | Typical triggers |
|---|---|---|
| LOW | Green shield | Read-only permissions, no network access, no executable code. Snippets, themes, prompt templates. |
| MEDIUM | Yellow shield | Limited file_write or network access, MCP server with scoped permissions. Configuration-level packages. |
| HIGH | Red shield | Broad 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
canUseToolcallback. 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 tier | Access level | Content types |
|---|---|---|
| Passive | Read-only. Can read files and display information but cannot modify anything. | Snippets, themes, prompt templates |
| Configuration | Settings access. Can read and write configuration files within defined scopes. | Agent presets, project templates, collections |
| Executable | Code 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:
- Flag the package as compromised in the marketplace registry
- Push a recall notification to all installations
- 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.