Aguara v0.4.0, MCP v0.3.0 & Watch Expansion — Coordinated Release

Today we ship simultaneous releases across three projects: Aguara v0.4.0, Aguara MCP v0.3.0, and a major Aguara Watch expansion. The common thread across all three: the entire stack now runs on the official modelcontextprotocol/go-sdk v1.4.0, the Linux Foundation Tier 1 SDK. Zero community forks remain. One SDK. One governance model. One dependency chain we actually trust.

This is what a coordinated release looks like when three projects share the same foundation. Scanner, MCP server, and observatory all moved forward together. Here is everything that shipped.

Aguara v0.4.0 — 153 Rules, Supply-Chain & File Hardening

Aguara v0.4.0 expands the rule set to 153 detection rules with five new rules targeting supply-chain abuse, TOCTOU patterns, and credential exposure. Alongside the new rules, this release hardens how Aguara handles files and memory, and improves the installation experience.

5 New Detection Rules

SUPPLY_017  (HIGH)    Hardlink workspace escape
                      ln without -s targeting sensitive paths outside
                      the workspace boundary. Hardlinks bypass directory
                      sandboxes because they reference inodes directly.

MCP_013     (HIGH)    Approval-execution binding gap
                      TOCTOU patterns where the tool description shown
                      at approval time differs from what executes.
                      Time-of-check vs time-of-use in tool invocation.

MCP_014     (HIGH)    Unscoped resource identifier
                      Resource access without ownership validation.
                      Tool accepts a resource ID but never checks whether
                      the caller is authorized to access that resource.

SSRF_011    (MEDIUM)  IPv6 multicast SSRF bypass
                      Requests targeting ff00::/8 multicast addresses.
                      Blocklists that only filter IPv4 private ranges
                      miss IPv6 multicast entirely.

CRED_020    (HIGH)    OAuth PKCE verifier exposure
                      code_verifier leaked in logs, error messages, or
                      client-side storage. The PKCE verifier is a secret
                      that must never leave the client.

Each rule follows the same pattern: detect a real attack vector observed in production MCP deployments or reported in the community. SUPPLY_017 came directly from a hardlink escape technique documented against container sandboxes. MCP_013 targets the approval-execution gap that several researchers flagged in MCP tool invocation flows. CRED_020 catches a pattern we found in 3 skills during Aguara Watch scans where OAuth PKCE verifiers were logged to stdout.

File & Memory Hardening

This release adds five guardrails to prevent Aguara itself from being a resource consumption vector or a path traversal target:

• Scan target size limit: files larger than 50 MB are skipped. Aguara is a static analysis tool, not a binary analyzer. No legitimate MCP config or skill definition is 50 MB.
• Custom rule validation: user-supplied rule files are validated for schema conformance before loading. Malformed rules fail fast with clear error messages.
• .aguara.yml size limit: configuration files larger than 1 MB are rejected. A 1 MB YAML config is not a config file.
• State file permissions: all state files written by Aguara use 0o700 for directories and 0o600 for files. No world-readable state.
• Symlink rejection: scan targets that are symlinks are rejected. Aguara follows the path you give it, not where a symlink points.

Additionally, the decoder pipeline now enforces bounds: files over 1 MB are skipped entirely, and individual decoded content is truncated at 512 KB. These limits prevent a crafted input from consuming unbounded memory during scanning.

Developer Experience

Two improvements to how developers install and configure Aguara:

• PATH hint after go install: if the Go binary directory is not in your PATH, Aguara now prints a shell-specific hint (bash, zsh, fish) showing exactly what to add. The hint is shown once per installation, not on every run.
• New curl|bash installer: the install script now verifies the downloaded binary against a SHA-256 checksum before placing it in your PATH. If the checksum does not match, the installer exits with an error. No silent failures.

# Install with checksum verification
curl -fsSL https://raw.githubusercontent.com/garagon/aguara/main/install.sh | bash

# Or install via Go
go install github.com/garagon/aguara@latest

Aguara MCP v0.3.0 — Official SDK & Operational Hardening

Aguara MCP v0.3.0 is the MCP server that exposes Aguara scanning capabilities to AI agents. This release is primarily about two things: migrating to the official SDK and hardening the server for production use.

SDK migration: Aguara MCP moved from mark3labs/mcp-go v0.44 to modelcontextprotocol/go-sdk v1.4.0. The community fork served its purpose, but the official SDK is now the right dependency. This migration removed 6 transitive dependencies from the module graph. Fewer deps, smaller attack surface, one governance model.

Scan timeout: every scan invocation now has a 30-second deadline. If a scan does not complete within 30 seconds, the MCP server returns an error to the client instead of blocking indefinitely. MCP clients should not hang because a scan target is adversarial or unusually large.

Error sanitization: internal errors are no longer forwarded to MCP clients. Before this release, a scan failure could leak internal paths, Go stack traces, or file system details to the client. Now, clients receive a generic error message. The full error is logged to stderr and only visible when running with --debug.

# Install Aguara MCP
go install github.com/garagon/aguara-mcp@latest

Aguara Watch — 42,969 Skills Across 7 Registries

Aguara Watch is the public observatory that scans AI agent skill registries 4 times daily with the full Aguara rule set. This release adds two new registries and nearly doubles total coverage.

Two new registries:

• Smithery: 100 skills added. A curated registry focused on production-quality MCP servers.
• Glama: 17,911 skills added. This single registry nearly doubled Aguara Watch's total coverage. Glama aggregates MCP servers from multiple sources, providing the broadest single view of the ecosystem.

Ecosystem health: across all 42,969 skills and 7 registries, 99% receive a Grade A security rating. The breakdown of findings: 159 critical, 784 high, 748 medium. The average security score is 99.5 out of 100. The ecosystem is generally healthy, but 159 critical findings across production registries means there is real work left to do.

Stack-Wide SDK Alignment

The biggest story in this coordinated release is not any single feature. It is that the entire stack now runs on the same SDK with zero community forks.

Both Aguara MCP and Oktsec migrated from mark3labs/mcp-go to the official modelcontextprotocol/go-sdk v1.4.0. The community fork was essential when the official SDK did not exist. Now it does. The Linux Foundation governs it. The MCP specification authors maintain it. Zero community forks remain across our projects.

One SDK. One governance model. One place to audit the dependency.

Oktsec v0.6.0 shipped alongside these releases with its own significant changes: a new MCP Gateway mode for proxying MCP traffic through a security layer, 21 SSRF CIDR blocks, 15 credential redaction patterns, and 17 MCP client discovery signatures. Full details in the Oktsec v0.6.0 release post.

By the Numbers

Key deltas between the previous releases and what shipped today:

Metric	Before	After	Delta
Aguara rules	148	153	+5
Registries	5	7	+2
Skills monitored	~18,000	42,969	~2.4x
Community SDK refs	3	0	-3

The skills monitored number is the one that stands out. Going from ~18,000 to 42,969 in a single release means Aguara Watch now covers the majority of the public MCP ecosystem. When a new supply-chain pattern emerges, we see it across 42,969 skills within hours.

What's Next

The rule set is heading toward 200+ rules. The next batch of rules will focus on agentic tool abuse patterns observed in real-world deployments: multi-step attack chains where individual tool calls look benign but the sequence is malicious, implicit permission escalation through tool composition, and data exfiltration via tool output channels.

These patterns are harder to detect with static analysis alone. They require understanding tool call sequences and context flow. That is the direction. More rules. Deeper analysis. Real patterns from production data.

We shipped three projects today. The foundation is aligned. Now we build on it.