AgentNode Security: Trust, Permissions & Safe Install

The Security Challenge for AI Agent Tools

AI agent tools present a unique security challenge. Unlike a library you import and call from your own code, agent tools are invoked autonomously by an LLM. The AI decides when to call a tool, what arguments to pass, and how to interpret the results. This means you need confidence in the tool before deployment, because there's no human reviewing each invocation in real time.

A malicious or buggy agent tool could exfiltrate sensitive data from your environment, modify files it shouldn't have access to, make unauthorized network requests, or simply produce incorrect results that corrupt downstream workflows. AgentNode's security model addresses these risks through multiple layers: trust levels that progress as packages prove themselves, explicit permission declarations, verification in an isolated sandbox, cryptographic signatures, hash-verified downloads, and automatic quarantine when something goes wrong.

Trust Levels: Earning Confidence Incrementally

Every package on AgentNode starts at the lowest trust level and must earn higher trust through objective, automated criteria. The four trust levels are:

Unverified

A newly published package begins as Unverified. It has been uploaded to the registry and its metadata is indexed, but no verification has run yet (or verification failed). You should treat Unverified packages with caution—they might work perfectly, or they might not even install. Only use Unverified packages in isolated development environments where you can inspect the code yourself.

Verified

A package reaches Verified status when it passes the core verification pipeline with a score of 70 or above. This means it installs correctly, its declared tools are importable and callable, the smoke test produced a valid result, and overall quality metrics meet the threshold. Verified packages have demonstrated basic functionality in an automated test environment.

Trusted

Trusted status indicates sustained quality over multiple versions and verification runs. A package earns Trusted status through consistent high scores, reliable performance across re-verification cycles, and absence of security findings. Trusted packages are suitable for production use cases where reliability matters.

Curated

Curated is the highest trust level and requires manual review by the AgentNode team. Curated packages have been inspected at the code level, their publishers have been verified, and they meet additional quality standards beyond what automated verification can check. This is reserved for high-impact packages where an extra layer of human review provides meaningful additional confidence.

The Permission Model

Every AgentNode package declares the permissions it needs. These declarations are part of the package manifest and are verified against actual behavior during the verification pipeline. The permission categories are:

Network Access

none: The tool makes no network requests. It processes data locally. This is the safest level for data-sensitive environments.
restricted: The tool needs network access but only to specific domains. The allowed domains are listed in the manifest (e.g., ["api.openai.com", "storage.googleapis.com"]). You can review exactly which endpoints the tool communicates with.
unrestricted: The tool may connect to any network endpoint. Common for web scraping tools or tools that interact with user-specified URLs. Use with more caution.

Filesystem Access

none: No filesystem access. The tool works entirely in memory.
temp: Access only to temporary directories. Files are created and cleaned up without touching your workspace.
workspace_read: Can read files from the current workspace but not modify them. Appropriate for analysis tools.
workspace_write: Can read and write files in the workspace. Needed for tools that generate output files.
any: Broad filesystem access. Rare and should be scrutinized carefully.

Code Execution

none: The tool doesn't spawn subprocesses or execute external commands.
limited_subprocess: The tool may run specific subprocesses (like calling ffmpeg for video processing) but doesn't need shell access.
shell: The tool needs full shell execution capability. This is the most permissive level and should be rare.

Data Access

input_only: The tool only processes data you explicitly pass to it. It doesn't access databases, accounts, or persistent storage.
connected_accounts: The tool may access external accounts you've connected (like an API key for a third-party service).
persistent: The tool maintains state between calls, storing data for later use.

When you install a package, you can review its permission declarations with:

agentnode info package-slug

This shows you exactly what the tool claims to need. If a "text summarizer" declares network: unrestricted and filesystem: any, that's a red flag worth investigating before installation.

Verification Sandbox: Isolated Testing

The verification pipeline runs in a controlled sandbox environment. In production, this is a Docker container with strict isolation:

Network isolation: After the install step completes (which needs network to download dependencies), the container's network is disabled with --network=none. Smoke tests and runtime checks execute in a fully offline environment. This prevents packages from making network calls during testing—if a tool tries to phone home, it simply can't.
Filesystem isolation: Each verification run gets a fresh, disposable filesystem. Nothing persists between runs, and the package can't access host files.
Resource limits: Containers have CPU and memory limits to prevent resource exhaustion attacks (like a package that tries to mine cryptocurrency during verification).
Time limits: Each verification step has strict timeouts. A package that hangs during import or takes too long during smoke tests is terminated and marked as failed.

This sandbox design means that even if a package contains malicious code, it can't cause harm during the verification process itself. The verification results then inform whether the package is safe for users to install.

Cryptographic Signatures: Ed25519

Package artifacts on AgentNode are signed using Ed25519 digital signatures. This provides:

Publisher authenticity: The signature proves the package was uploaded by the claimed publisher. If someone compromises the registry storage but not the publisher's signing key, they can't inject modified packages.
Tamper detection: Any modification to the package artifact after signing will invalidate the signature. You can verify that the package you download is byte-for-byte identical to what the publisher uploaded.
Ed25519 specifically: This algorithm was chosen for its speed, small key size, and resistance to timing attacks. Signatures are compact (64 bytes) and verification is fast, so it doesn't add latency to the install process.

Hash-Verified Downloads

Every package artifact stored on AgentNode has a SHA-256 hash recorded at upload time. When you install a package, the SDK downloads the artifact and verifies its hash before unpacking:

# This happens automatically during install
# The SDK compares the download hash to the recorded hash
agentnode install pdf-reader-pack

If the hash doesn't match—whether due to a corrupted download, a man-in-the-middle attack, or storage corruption—the installation fails with a clear error. The SDK will not install a package whose hash doesn't match the registry's record.

This is a defense-in-depth measure that works alongside Ed25519 signatures. Even if an attacker could forge a signature (extremely unlikely with Ed25519), the hash check provides an independent verification path.

Automatic Quarantine

AgentNode includes an automatic quarantine system that isolates packages when problems are detected. A package version can enter quarantine for several reasons:

Verification failure after previously passing: If a re-verification run fails for a package that previously passed, it may be quarantined pending investigation.
Security findings: The platform runs static analysis (including Bandit for Python) as part of the publishing process. High or critical severity findings can trigger automatic quarantine.
Typosquatting detection: AgentNode checks new package names against existing popular packages. If a package name is suspiciously similar to an established package (like pdf-reader-pakc vs pdf-reader-pack), it may be quarantined for review.
Community reports: Users can report packages, and reported packages undergo additional scrutiny.

Quarantine has four states:

none: Normal status. The package is available for installation.
quarantined: The package is isolated. It won't appear in search results and can't be installed until the issue is resolved.
cleared: After investigation, the package was found to be safe and returned to normal status.
rejected: After investigation, the package was found to be problematic and permanently removed from the registry.

Static Security Analysis

During the publishing process, AgentNode runs automated security scanning on package source code. This includes:

Bandit scanning: A Python-focused static analysis tool that detects common security issues like hardcoded passwords, use of eval(), unsafe deserialization, and potential SQL injection patterns.
Dependency auditing: Checking installed dependencies against known vulnerability databases.
Pattern matching: Detecting suspicious patterns like obfuscated code, encoded payloads, or attempts to access system credentials.

Security findings are recorded with severity levels (low, medium, high, critical) and are visible to users reviewing a package. High and critical findings may trigger automatic quarantine.

How to Evaluate Package Safety

When deciding whether to install an AgentNode package, use this checklist:

Check the trust level. Curated and Trusted packages have the most evidence behind them. Verified packages have demonstrated functionality. Unverified packages need manual review.
Review the verification score and tier. Look at the per-step breakdown. A package that passes install and import but has an inconclusive smoke test due to credential requirements is very different from one that fails at installation.
Read the permission declarations. Does the tool need the permissions it claims? A text processing tool shouldn't need network access. A file converter might reasonably need filesystem read/write. If permissions seem excessive for the tool's stated purpose, investigate further.
Check the confidence level. A high-confidence score means the verification pipeline collected strong evidence. A low-confidence score means uncertainty—the tool might be great or might have issues that weren't caught.
Look at the publisher. Is this publisher's account verified? Do they have other packages with good verification scores? Consistent quality across a publisher's catalog is a positive signal.
Review the source code. If the package has a linked source repository, examine the code. This is especially important for packages requesting elevated permissions. The source URL is available via agentnode info package-slug if the publisher provided it.
Test in isolation first. Before using a package in production, test it in a development environment. Run the tools with sample inputs and verify the outputs match your expectations.

CI/CD Security with GitHub Actions

For publishers, AgentNode provides a GitHub Action that integrates with your CI/CD pipeline:

# .github/workflows/publish.yml
name: Publish to AgentNode
on:
  push:
    tags:
      - 'v*'
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: agentnode/publish@v1
        with:
          api-key: ${{ secrets.AGENTNODE_API_KEY }}

Publishing through CI/CD provides additional security benefits: the package is built from a known git commit, the build environment is reproducible, and the provenance chain (source commit, build system, artifact hash) is recorded in the registry. This makes it harder for an attacker to insert malicious code, since the entire build process is auditable.

Defense in Depth

No single security measure is sufficient on its own. AgentNode's security model works through layered defenses:

Publisher authentication ensures only authorized users can publish packages
Ed25519 signatures prove artifact authenticity
SHA-256 hash verification detects tampering during download
Static analysis catches known vulnerability patterns in code
Sandbox verification tests runtime behavior in isolation
Permission declarations make access requirements transparent
Trust levels provide a progressive quality signal
Auto-quarantine isolates problems when detected
Typosquatting detection prevents name confusion attacks

Each layer catches threats that other layers might miss. A well-crafted malicious package might pass static analysis but fail sandbox verification. A typosquatting package might install fine but get caught by the name similarity check. The combination of all these measures provides stronger protection than any single mechanism.

Summary

AgentNode's security model is built for the specific challenges of AI agent tools: autonomous execution, opaque decision-making, and the need for pre-deployment confidence. Trust levels provide a progressive quality signal from Unverified to Curated. Permission declarations make access requirements explicit and reviewable. The verification sandbox tests tools in an isolated container with network disabled. Ed25519 signatures and SHA-256 hashes ensure artifact integrity. Auto-quarantine isolates problems reactively when they're detected. Together, these mechanisms give you the information and protection you need to make informed decisions about which tools to give your AI agents.