How SwarmSpace maps to the OWASP AST10 framework (v1.0, 2026 Edition). This page is for developers and security reviewers evaluating the platform.
The manifest spec includes Ed25519 signing and content_hash (SHA-256) fields for verifying plugin authenticity. Trust revocation is instant — removing a plugin from the index disables it universally with no uninstall needed, which is architecturally true today.
No signing or verification code has been implemented yet. The Ed25519 and content-hash fields exist in the spec only. Until signing is enforced, authenticity verification depends on manual review during submission.
The manifest spec includes Ed25519 signing and content_hash fields for integrity verification. Plugins are API endpoints, not installable code — there are no executable uploads, which eliminates an entire class of supply-chain vectors.
No hash verification code exists yet. While the API-endpoint architecture avoids binary supply-chain risks, manifest integrity checking is spec-only and not enforced at runtime.
The manifest spec defines network_permissions (explicit domain allowlist replacing binary network on/off), deny_write (protects identity, memory, and context files), and data_required (declares what user data a plugin needs). These fields enable fine-grained least-privilege declarations.
No code currently validates or enforces these constraints at execution time. The fields exist in the manifest schema but are not checked at the runtime layer. Until enforcement ships, privilege restriction depends on manual review.
Inconsistent or misleading metadata formats allow skill impersonation and misrepresentation.
scan_status field records scanner version and results in the manifestcapability vs data_required fieldscapability, data_required, network_permissions, etc.)No runtime enforcement of metadata accuracy — a plugin’s declared capabilities may differ from its actual behavior. Metadata fields are declared but not validated against actual plugin behavior at runtime. Ed25519 signing of metadata is spec-only (no verification code exists).
YAML/JSON/Markdown deserialization vulnerabilities enable code execution on skill load.
Plugin JSON responses are not validated against a declared output schema before being passed to agents, which leaves a vector for malformed or adversarial output injection.
Running skills without containerization/sandboxing exposes the host system.
Credential isolation is not yet scoped per-tenant. Plugin credentials are shared across tenants rather than isolated per-user context.
The manifest spec includes a version_pinning field that enables consumers to lock to specific plugin versions. This is a prerequisite for safe updates and rollback.
No pinning or version-check code exists yet. Alerting on plugin updates and re-review flagging are planned but not implemented. Plugins can change behavior between calls without any notification to consumers.
scan_status field records scanner version and results in the manifestcapability vs data_required fieldsA full behavioral and semantic scanning pipeline is not yet deployed. Plugin review is currently manual. Automated runtime behavioral analysis and continuous scanning are planned.
The risk_tier field (L0–L3) exists in the manifest spec but is not enforced at runtime. Governance tooling for automated merit reviews and tier transitions is planned but not yet built.
Security properties lost when skills are ported across platforms without translation.
network_permissions, deny_write, risk_tier) that travel with the plugin declarationSecurity properties defined in the manifest are only enforced within the SwarmSpace runtime. When plugins are accessed outside the SwarmSpace router (e.g., direct API calls), declared security properties like network_permissions and deny_write have no enforcement mechanism. No cross-platform security property translation or verification exists.
OWASP defines the lethal trifecta as three capabilities that, combined, create maximum risk for agentic systems.
| Channel | SwarmSpace control | Status |
|---|---|---|
| Access to private data | data_required field + PRISM consent flow |
Designed, not enforced |
| Exposure to untrusted content | Output schema validation + untrusted data wrapping | Planned |
| Ability to communicate externally | network_permissions allowlist + deny_write protection |
Spec only, no enforcement |
PRISM consent fields are defined in the manifest spec; runtime enforcement is not yet in place. Full lethal trifecta coverage requires implementing the controls listed in the Compliance Timeline below.
| Milestone | Status |
|---|---|
| Manifest spec aligned with AST10 fields | Complete (spec only — no runtime enforcement) |
| PRISM consent flow for privacy-sensitive plugins | Designed, not enforced |
| Activity logging and observability | Complete |
| Ed25519 manifest signing for Verified tier | Designed (no signing code exists) |
Runtime enforcement of network_permissions, deny_write, risk_tier | Planned |
| Output schema validation for plugin responses | Planned |
| Version pinning and update alerting | Planned |
| Behavioral scanning pipeline | Planned |
network_permissions, deny_write, and risk_tier fields exist in the manifest spec but have zero runtime enforcement. Plugins can currently make any network call and access any data, constrained only by V8 isolate boundaries.data_required and network_permissions are declared in manifests but not validated or restricted at the execution layer.risk_tier (L0–L3) is recorded but does not gate plugin behavior or access levels.