Autonomous AI agents have reached global deployment scale. The most widely adopted open-source agent framework crossed 180,000 GitHub stars after its viral adoption in late January 2026[12], and on February 9, 2026, a live internet-wide scan counted more than 135,000 publicly exposed instances[14]. These agents run with full system access: reading files, executing shell commands, sending emails, signing financial transactions, and controlling physical devices. They operate continuously, retain persistent memory across sessions, and make autonomous decisions without human review.
The security consequences have been severe: at least 230 malicious skills in the community skill repository within a week, an autonomous transaction error with a large financial loss, and a national government restricting use in state-run enterprises. Security researchers mapped the leading framework against every category of the OWASP Top 10 for Agentic Applications[7].
These reports raise questions about permissions, enforcement boundaries and retained records. They do not establish one root cause across all exposed instances, or show that a signed record would have prevented the incidents. This analysis examines four design concerns, explains where AGA could contribute and states what the published packages do not address.
1. The scale of ungoverned autonomy
The open-source autonomous agent category crossed a threshold in early 2026. What had been a developer experiment became a global deployment phenomenon, with agents running on personal laptops, corporate workstations, cloud infrastructure, and state enterprise systems.
One internet-wide scan identified 42.9K unique IP addresses hosting exposed control panels across 82 countries, with 15.2K instances appearing vulnerable to remote code execution[1]; within hours its live dashboard showed more than 135,000 exposed instances, with more than 50,000 vulnerable to remote code execution[14]. Another observed over 30,000 exposed instances in a two-week window[2]. A third tracked growth from roughly 1,000 to over 21,000 publicly exposed instances in a single week[3]. An independent study identified at least 42,665 exposed instances and actively verified 5,194 of them, of which 93.4% exhibited critical authentication bypass vulnerabilities[4].
The supply chain picture is worse. Academic researchers analyzed 31,132 community-contributed agent skills and found that 26.1% contained at least one vulnerability[15]. A security team tested the top-ranked skill in the community repository and found it was functionally malware: it silently exfiltrated data to attacker-controlled servers and used direct prompt injection to bypass safety guidelines[5]. Separate analysis counted at least 230 malicious skills uploaded to the repository in a single week[6].
One analysis mapped the leading agent framework against every category of the OWASP Top 10 for Agentic Applications and described “near-absent governance protocols”[7]. The researcher who coined the term “prompt injection” identified three properties that together form a “lethal trifecta” for AI agents: access to private data, exposure to untrusted content, and the ability to communicate externally[8]. The same analysis[7] added a fourth: persistent memory, which enables delayed-execution attacks where malicious instructions embedded in content sit dormant for days before triggering.
Government authorities restricted state enterprises from running autonomous AI agents, citing security concerns[9], after adoption had spread quickly through enterprises[10].
In the financial domain, an autonomous agent with wallet signing authority, tasked with distributing small token rewards, reportedly signed away a large sum in a single transaction after a session crash and a parsing error[11]. It had signing authority over a wallet with no governance boundary in front of it.
Broad delegated access can amplify the consequences of a compromised or mistaken agent. Reviewing that risk requires the actual configuration, enforced permissions and available recovery controls, not just the framework name or an exposure count.
2. Four architectural failure modes
The reports raise four design questions. The following sections distinguish architectural proposals from shipped functionality. Configuration, permissions and deployment-specific controls remain part of the explanation; these reports are not an audit of every affected system.
Failure mode 1: no proof of origin
When an agent loads a community-contributed skill, there is no cryptographic binding between the skill's claimed identity and its actual contents. The skill executes with the agent's full system permissions. Researchers demonstrated this by analyzing the top-ranked skill in the largest agent skill repository: it contained hidden instructions to exfiltrate data to an external server, and it had been promoted to the top position through ranking manipulation[5].
In the architecture, the boundary hashes each component before execution and compares it with the sealed reference, sealing a DENY decision on a mismatch. That is design, not a shipped feature: the published packages do not hash skills or components, and aga-mcp-server hashes only content the caller supplies.
Failure mode 2: no runtime governance boundary
The cited analysis examines a risky combination: private data, untrusted content, external communication and persistent memory.[7] These capabilities can be useful, but reviewers should check how permissions and boundaries constrain them. This is not a claim that all current agents have unrestricted system access or lack policy controls.
The gateway addresses this by interposing a separate process between the agent and the resources it acts on. The agent holds no signing key when the gateway runs under its own identity. When the deployment makes the gateway the agent's only route, each tool call is evaluated against the policy before it goes anywhere: an out-of-policy call gets a signed DENIED receipt, and in-path, aga-proxy does not forward it. Whether the agent has another route is a property of the deployment, and the record does not prove it.
Failure mode 3: no behavioral governance
Prompt injection changes agent behavior without modifying the agent's binary. Integrity measurement of files produces clean results even when the agent is fully compromised through adversarial inputs. The agent's code is untouched; its decisions are manipulated.
Behavioral checks address part of this by watching observable patterns: which tools the agent invokes, in what sequences, at what rates. Under an allowlist policy, the published aga-proxy applies the tool list, rate limits, and path and substring rules to each tools/call; its default profile applies none of them, and a denylist policy applies no path or substring rules (known issue 10 on /security says what they check). aga-mcp-server 3.6.0 through 3.6.2 adds a rule-based check of its own governed tools against permitted tools, forbidden sequences and rate limits, run when the client calls it; it records a signed drift finding and, by default, only detects. None of this detects prompt injection as such. In the architecture, a drift finding can call for phantom execution, which exists only in a demo orchestrator. We described the design in our first article.
Failure mode 4: no tamper-evident accountability
If an agent's only operational history is in mutable local files it can rewrite, compromise can undermine that record. Separately collected logs, protected storage and exported checkpoints can change that threat model. Review who can alter or delete each copy, rather than assuming every agent deployment has the same storage arrangement.
A signed receipt chain addresses this by recording each governance decision as its own receipt. Each receipt references the previous receipt's hash, so altering any decision breaks verification against a pinned key, and hiding the change means re-signing every later receipt with a key the agent does not hold when the gateway runs under its own identity.
Arguments are committed by SHA-256 hash, so verification never requires disclosing argument contents; in 3.6.0 through 3.6.2, a path-constraint denial records the offending path in its signed reason, and a denied-pattern denial records the matched pattern. The chain is bound by a signed checkpoint over its count, head and Merkle root, so a truncated tail is detectable offline against the pinned key. An earlier genuine export presented as the current one still verifies, because the verifier has no freshness input. Publishing that checkpoint to an append-only log you operate is a deployer integration that is not shipped.
The receipts, Merkle inclusion proofs, signed checkpoint and public key are packaged into an Evidence Bundle: standard JSON that any party can verify using Ed25519 signature verification and SHA-256 hashing. No network access to the original system and no proprietary software. The reviewer no longer relies on the operator's logs; what remains is trust in the key they pinned.
3. The architecture
The governance process operates in four steps. It uses standard cryptographic primitives: Ed25519 for digital signatures, SHA-256 for hashing, a JCS-lineage scheme for JSON canonicalization, and Merkle trees for batch integrity proofs. No trusted execution environments and no zero-knowledge proof circuits are required, and the architecture runs on commodity hardware.
Seal: fix the policy before the agent operates.
In the architecture, the agent's approved state and governing policy (approved tools, forbidden sequences, rate limits, TTL, governance triggers) are locked into a signed Policy Artifact; checked against the issuer's pinned key, any modification made without the signing key breaks its signature. In the published aga-proxy, the policy is a JSON file, and every receipt carries the signed SHA-256 of the policy's canonical JSON, so reformatting the file does not change it.
Capture: decide at the boundary, and sign the decision.
A separate process, the gateway, sits between the agent and the tools it calls. When the deployment routes all external access through it, the agent has no bypass path; it holds no signing key when the gateway runs under an OS identity the agent cannot read. The published aga-proxy evaluates each tools/call against the policy and signs PERMITTED or DENIED (known issue 7 on /security describes the exceptions). In aga-mcp-server 3.6.0 through 3.6.2, a measurement mismatch puts the server in QUARANTINE, and a revocation, or a TTL expiry found at the next measurement, puts it in TERMINATE; both verdicts stay in process, and the exported bundle shows the governed calls refused afterward and, for a revocation, the revoke_artifact call itself. The governed client can lift a quarantine, revocation or termination by calling attest_subject, and the exported bundle does not record that call. In the architecture the boundary can also compare the agent's binary with the sealed reference before each operation; the published packages do not. Effecting a decision beyond aga-proxy's own forwarding is wired per deployment.
Record: each recorded decision is a signed receipt.
Each decision the gateway records is a signed Decision Receipt, appended to the receipt chain (known issue 7 on /security describes the calls aga-proxy refuses without a receipt). The result is a cryptographic record of the decisions the boundary made, where altering any of them breaks verification against a pinned key, and hiding the change means re-signing every later receipt; a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security). When the gateway runs under an OS identity the agent cannot read, an attacker who compromises the agent does not gain the signing key, which lives in a separate process, so it cannot alter the exported record without detection. Receipts not yet exported live in the gateway's memory and are lost if its process ends, and ending that process needs no key. A compromised gateway host is a different matter, and is out of scope.
Verify: portable proof without network access.
Evidence Bundles verify without network access. The verifier checks every receipt signature, every Merkle inclusion proof, and the signed checkpoint, fully offline, and any party with standard tools can repeat the check.
Performance
Signing cost and overall latency depend on the workload and host. In 3.6.0 through 3.6.2 bundle export is quadratic in the receipt count and holds governed calls while it runs. The repository's benchmark script measures the per-call path on an approved evaluation host; no general production performance guarantee is made here.
The retained 3.6.0 CI record, reviewed September 21, 2026, reports 428 automated tests covering cryptographic primitives, protocol operations, tool handlers, integration scenarios, and tamper resistance, with a retained conformance snapshot reporting verdicts identical across three toolchains (JavaScript, Go, Python) on all 61 classical cross-stack cases as the harness feeds them (it re-serializes the parsed cases, so the leaf_index case spelled 0.0 runs as an integer; see /spec) and two language oracles agreeing on all 28 post-quantum composite cases. It is available on npm: an MCP server with a governance toolset, and aga-proxy, which governs another MCP server's tool calls (its agent port is raw newline-delimited TCP, so a stdio MCP client needs a relay you provide; none ships). We detailed how AGA records MCP server decisions in our previous article.
4. Mapping to published security frameworks
The table below uses OWASP's own categories[13] and states, for each, what the published 3.6.0 through 3.6.2 packages do about it. Most are not addressed.
| OWASP category | Status in 3.6.0 to 3.6.2 | What the published packages do |
|---|---|---|
| ASI01: Agent Goal Hijack | Not addressed | A hijacked agent's out-of-policy tool calls are still denied and recorded by aga-proxy; the hijack itself is not detected. |
| ASI02: Tool Misuse and Exploitation | Partial | Under an allowlist policy, aga-proxy applies the tool list, rate limits, and path and substring checks to each tools/call and signs the decision (known issues 7 and 10 on /security describe the exceptions and what the checks cover). |
| ASI03: Identity and Privilege Abuse | Partial | When the gateway runs under its own identity the agent holds no signing key, and the allowlist bounds what it can call through the gateway. There is no identity management. |
| ASI04: Agentic Supply Chain Vulnerabilities | Not addressed | The published packages do not verify skills, models or dependencies. |
| ASI05: Unexpected Code Execution (RCE) | Not addressed | Substring denials on a shell tool are lexical rules, not a sandbox. |
| ASI06: Memory & Context Poisoning | Not addressed | AGA does not inspect agent memory or context. |
| ASI07: Insecure Inter-Agent Communication | Not addressed | AGA does not secure the channel between agents. |
| ASI08: Cascading Failures | Not addressed | A per-gateway record does not contain failures across agents. |
| ASI09: Human-Agent Trust Exploitation | Not addressed | AGA records tool-call decisions, not what an agent tells a person. |
| ASI10: Rogue Agents | Partial | A rogue agent's tool calls through the gateway are recorded and out-of-policy ones denied; calls that bypass it are not recorded. |
The architecture also maps, narrowly, to established federal security frameworks.
NIST AI RMF (AI 100-1). A signed record of recorded proxy decisions can support selected Measure and Manage review tasks; it does not establish framework compliance. The published packages do not measure on a schedule, and effecting a decision beyond aga-proxy's own forwarding is wired per deployment.
NIST SP 800-207 (Zero Trust Architecture). For tool calls that pass through it, aga-proxy sits where an SP 800-207 policy enforcement point would; whether all of an agent's traffic passes through it is a property of the deployment.
NIST SP 800-218 (Secure Software Development Framework). The SSDF governs how software is built, so a runtime decision record is not an SSDF control. Integrity information must be checked for the exact release. As of September 30, 2026, aga-mcp-server 3.6.5 has a provenance attestation with a matching archive digest and accepted source commit; aga-verify 2.2.3 was manually published and has no SLSA provenance attestation. Registry signatures and retained hashes are separate checks. See the release provenance record for the version-specific evidence. None of these checks establishes SSDF conformity by itself.
NIST SP 800-53 Rev. 5. The signed receipt chain may support selected AU (Audit and Accountability) review tasks, depending on the control and deployment: checked against a pinned gateway key, a record cannot be rewritten without breaking the chain forward, except by the key holder, who can re-sign. For SI (System and Information Integrity), the packages supply the integrity of the record itself (SI-7) and receipts for recorded decisions that SI-4 monitoring could draw on (scoped to calls that pass the gateway); they add no integrity check of the software.
5. What this means for autonomous agent deployment
The question is no longer whether autonomous AI agents should exist. Over 180,000 GitHub stars, adoption by enterprises across multiple continents, and integration with financial systems and physical infrastructure have settled that. Autonomous agents are here.
The question is whether the governance architecture exists to make them accountable.
The cited incidents justify examining authority, reachable resources, policy enforcement and record protection. They do not prove that every deployment lacks those controls, or that one record format solves the underlying security problems.
These are engineering problems with concrete solutions.
Logging, allowlists and permission prompts can contribute to that design. Whether their outputs are independently retained, signed or offline-checkable depends on the implementation. AGA offers one specific signed export for the proxy decisions it records.
Autonomous systems operating with delegated authority need a policy fixed before they run, a decision at the boundary for each action, and a signed record of those decisions that a reviewer can check offline. The published packages provide the last two for MCP tool calls routed through the gateway; scheduled measurement and containment are architecture, not shipped.
The governance process does not replace the agent framework. It wraps it. The agents continue doing what they do. The record shows what was decided at the boundary; it does not prove that nothing went around it.
npm · Specification · Technology
References
- SecurityScorecard STRIKE Team, research on internet-exposed instances of an open-source agent framework, February 9, 2026.
- Bitsight, research on autonomous agent instances exposed between January 27 and February 8, 2026, February 2026.
- Censys, research on the growth of publicly exposed AI agent instances, January 2026. censys.io
- Maor Dayan, a study that identified at least 42,665 exposed AI agent instances and actively verified 5,194, January 31, 2026.
- Cisco AI Defense Team, Cisco Blogs, an analysis of the security risks of personal AI agents and their community skills, January 2026.
- AuthMind, an analysis of malicious skills uploaded to an open-source agent framework's skill repository and what they mean for identity security, February 2026.
- Palo Alto Networks, an analysis that maps an open-source agent framework against the OWASP Top 10 for Agentic Applications as an emerging security risk, January 29, 2026.
- “The lethal trifecta for AI agents: private data, untrusted content, and external communication.” Simon Willison, June 16, 2025. simonwillison.net
- Tom's Hardware, a report on an open-source agent framework's rapid adoption in China and on authorities barring state-run enterprises from using it, March 11, 2026.
- Bloomberg, a report on how an open-source agent framework drove agentic AI adoption in China and on the security concerns it raised, March 12, 2026.
- CryptoTicker, an article on the performance and risks of AI trading with an open-source agent framework, March 2026.
- Conscia, an article on the security incidents around an open-source agent framework, February 18, 2026.
- “OWASP Top 10 for Agentic Applications for 2026.” OWASP GenAI Security Project, December 9, 2025.
- The Register, a report on the live count of internet-exposed instances of an open-source agent framework on SecurityScorecard STRIKE's dashboard, February 9, 2026.
- Yi Liu et al. “Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale.” arXiv:2601.10338, January 15, 2026. arxiv.org
See the working implementation on npm.
AGA is a reference implementation of a published format for verifiable decision records: hash-bound policies, signed Decision Receipts, and Evidence Bundles that verify offline. The implementation is on npm. The evaluation path walks through it in working code.