EnigmAgent

Local encrypted credential storage and operator-approved execution for AI agents. The integrated 3.0.0 release contains an authenticated vault, a Node administrator, a bounded MCP/REST gateway, a Python client and ten native framework integrations.

Contents — Start here · Why a fixed-operation broker? · Background · Native integrations · Authenticated storage · Verify from source · Historical platform code · Real-world applications · Observations and limitations · Possible improvements · Future work · Contributing and citation · Bibliography

Start here

_{Fig. 1 — What the 3.0.0 release contains. Source: docs/INTEGRATED_RELEASE_V3.md.}

Goal	Entry point
Understand what is released and tested	Integrated release v3
Download the versioned distributions	GitHub releases
Use a native agent framework	Python SDK
Run the MCP/REST gateway	Gateway
Manage a vault without writing application code	Administrator
Run a source-pinned container	Container
Check security boundaries	Threat model and security policy
Inspect earlier source versions	Preserved versions
Review integration evidence	Native runtime evidence

Package registry versions and browser-store packages are separate publication channels. A GitHub source change does not silently update npm, PyPI, a browser extension or a user's existing installation. Use the versioned release artifacts and their checksums; inspect a registry's actual version before installing it.

Why a fixed-operation broker?

_{Fig. 2 — Agent mode, schematic. Source: this section and operation-broker.js.}

A tool that returns a decrypted credential also gives that credential to its caller. Placeholder syntax alone cannot keep it out of an agent's context. EnigmAgent therefore separates two modes:

• Agent mode: the operator defines fixed GET/HEAD operations. The agent selects only an operation name. The broker attaches the credential to the configured destination and returns only {operation, status, ok}. Upstream response bodies and headers are discarded, including reflected or encoded credentials.
• Explicit trusted-backend mode: raw resolution requires deliberate opt-in. It is incompatible with the operation-broker transport and is not a model-isolating interface.

_{Fig. 3 — A real local run with synthetic values: the reflected credential never appears in the result, and unlisted names never reach the target.}

Default MCP mode exposes metadata only. REST always requires authentication. The broker allows public IPv4 HTTPS destinations. Fixed 127.0.0.1 HTTP destinations require explicit operator enablement. Redirects, user-selected URLs/headers and private/reserved egress destinations are not accepted.

_{Fig. 4 — The broker's fixed egress refusals and a real run of isPublicIPv4.}

Background

_{Fig. 5 — Milestones behind this design. Sources: the bibliography below.}

The broker answers an old question in a new setting. Saltzer and Schroeder set out the design principles of protection mechanisms in 1975, least privilege among them: every program should run with the smallest set of privileges it needs [1]. Hardy's confused deputy, a program that holds authority for one purpose and is steered by a caller into using it for another, is the failure that a credential-holding tool invites when its caller may name the destination [2]. Here the caller names only an operation; the destination, method, header and credential are fixed by the operator.

The storage layer rests on standard primitives. Authenticated encryption with associated data protects a message and also authenticates a header that is sent in the clear [3]; Galois/Counter Mode is an AEAD mode with published security and performance analysis [4], standardised by NIST [5] and given a common algorithm interface by RFC 5116 [6]. EnigmAgent seals the whole entry set with AES-256-GCM and binds the envelope header (format version, KDF parameters and salt) as associated data. The key comes from Argon2, the memory-hard password-hashing function that won the Password Hashing Competition [7] and is specified for Internet protocols in RFC 9106 [8]; the vault fixes Argon2id with t=3, m=65536 and p=1, and the repository's own roadmap still lists an independent review of those parameters as open. The broker's egress refusals are written as fixed IPv4 ranges, most of which are special-purpose blocks in the IANA registries described by RFC 6890 [9], and it attaches the credential in a standard bearer header by default [10].

What changed is who calls the tool. Greshake and colleagues showed that prompts planted in data an LLM-integrated application retrieves can steer it without the attacker ever talking to it [11]; AgentDojo turned this into an extensible environment of realistic agent tasks with security test cases, attacks and defences [12]; OWASP lists prompt injection first among LLM application risks [15]. Defences have moved from persuading the model to removing its authority: CaMeL extracts control and data flow from the trusted query so untrusted data cannot change the program, and enforces capabilities at tool calls [13], and Beurer-Kellner and colleagues collect design patterns that trade some generality for resistance that does not depend on the model [14]. EnigmAgent's agent mode is a narrow instance of that idea for credentials, exposed over the Model Context Protocol [16]. The author's later paypal-agentic-guardrail reuses this vault and adds a payment broker on the write path [17].

Native integrations

_{Fig. 6 — Runtime checks per framework. Data: audit/integration-runtime-evidence.json.}

Framework	Factory key	Tested package	Version
LangChain	langchain	langchain-core	1.6.3
LangGraph	langgraph	langgraph	1.2.11
LlamaIndex	llamaindex	llama-index-core	0.14.24
CrewAI	crewai	crewai	1.15.22
Haystack	haystack	haystack-ai	3.1.1
Microsoft Agent Framework	agent_framework	agent-framework-core	1.18.0
smolagents	smolagents	smolagents	1.26.0
Agno	agno	agno	3.0.10
PydanticAI	pydantic_ai	pydantic-ai-slim	2.44.0
AutoGen Core	autogen	autogen-core	0.7.5

These are third-party compatibility integrations maintained in this repository. Each is executed against a synthetic encrypted vault and a real authenticated local service. The tests check native results, available tracing/serialization surfaces and rejection of unknown operations. They are not claims of upstream endorsement, upstream merge, model quality or formal noninterference.

LangGraph includes checkpoint inspection. Haystack includes a serialized pipeline round trip with an explicit trusted-module allowlist. PydanticAI executes a local FunctionModel-driven agent loop; it does not call a paid model. MCP interoperability is also checked with the independently installed official Python MCP client.

Authenticated storage

_{Fig. 7 — Vault format v2, schematic. Source: vault-core.js.}

New vaults use Argon2id and AES-256-GCM. Vault format v2 authenticates the complete entry set together, including names, domains and values. The envelope header is bound as associated data. Writes are revision-checked and atomically replace the current file after a flushed temporary write. A failed write does not update the session's committed in-memory state. Failed unlock attempts lock the old session.

_{Fig. 8 — A real local run: a wrong password, a flipped ciphertext bit and a flipped salt bit each give vault_authentication_failed.}

Legacy format v1 is read-only until an explicit migration. Migration verifies all entry ciphertexts and preserves the original file as a permanent .v1-backup, as well as the rolling .bak. Legacy domain metadata was not authenticated by v1; its historical correctness cannot be recovered cryptographically by migration. Review old bindings and independently configure approved destinations.

_{Fig. 9 — The documented migration path, schematic. Source: docs/INTEGRATED_RELEASE_V3.md.}

_{Fig. 10 — A real local run of domain binding with a synthetic secret.}

A compromised broker process, administrator or operating system is outside this boundary. Hostile generated code needs an independently permissioned broker account/container; sharing an OS identity is not a sandbox. See the threat model for backup, rollback, Windows permissions and resource-limit qualifications.

_{Fig. 11 — The documented limits. Source: docs/INTEGRATED_RELEASE_V3.md.}

Verify from source

_{Fig. 12 — The commands below, run on a clean copy: 110 of 110 Node tests pass, as recorded in audit/integrated-local-validation.json.}

Use Node.js 22 or newer. The full native integration matrix is tested with Python 3.12; the dependency-light client requires Python 3.10 or newer.

cd platforms/mcp-server
npm ci --ignore-scripts --no-audit --no-fund
npm test
node tests/verify-package.mjs

The integrated GitHub workflow additionally executes the Python integrations, installs built packages in clean environments, and starts the actual Docker image. Tagged release publication depends on those checks succeeding. No recurring maintenance task or mass outreach is configured.

Historical platform code

_{Fig. 13 — Validated and historical components. Source: platforms/README.md.}

The browser extension, PWA, native GUI/IDE/mobile wrappers and older integration prototypes remain available as historical source. They are not certified by the Node/Python v3 release tests, and legacy v1 browser storage is not interchangeable with the new v2 Node vault. Their original files are also retained in the complete versioned source archives. Platform status distinguishes validated components from historical material instead of advertising every folder as a completed supported product.

Real-world applications

_{Fig. 14 — Potential uses that follow from the documented design. Each needs its own configuration and isolation.}

These are potential uses of the released components, not deployments. Each would need its own operator configuration, its own broker identity or container, and a review of the qualifications in the threat model.

• Tools for agent frameworks. An agent in one of the ten tested frameworks checks or calls an API by operation name and receives {operation, status, ok}, never the credential or the response body.
• MCP clients. The default MCP mode exposes metadata only; with a broker, a client lists and executes operator-approved operation names [16].
• Write-path brokers built on the vault. paypal-agentic-guardrail keeps its PayPal credential in this vault, bound to the sandbox host, and adds its own broker for payment writes [17].
• Operator-managed secrets. The administrator keeps credentials in one authenticated file without putting a value on a command line, with explicit migration, backups and recovery.
• Isolated containers. The source-pinned, non-root image runs the broker under its own identity, which is the operational separation the threat model asks for when generated code is untrusted.
• Reproducible security evidence. Synthetic fixtures and recorded runtime evidence let a reviewer rerun the boundary checks without real credentials.

Observations and limitations

_{Fig. 15 — Schematic summary of the qualifications stated in the README and docs/THREAT_MODEL.md.}

This section gathers, in one place, qualifications the repository already states; nothing here is new evidence.

• Raw resolution returns plaintext. A raw resolver gives the value to its caller, and placeholder syntax is not a security boundary. Raw resolution is disabled by default and cannot share a transport with the broker.
• Status and timing still flow back. A malicious destination controls its status and timing; the bounded result policy is not formal noninterference or a no-side-channel proof.
• The host is trusted. An administrator, a compromised operating system, the broker process or a same-identity debugger may read credentials or replace policy, and memory erasure in JavaScript or Python is not guaranteed.
• One token, not RBAC. A connection token grants the whole configured operation set; it is not per-user, per-operation or multi-tenant authorization.
• Replay and history. Replay of an entire previously valid vault is not detected without an external trusted version anchor, and legacy v1 domain metadata cannot be authenticated after the fact.
• Scope of the evidence. The native-framework runs are compatibility and security regressions on synthetic data, not a model benchmark, an external penetration test, or upstream endorsement. The release record lists Python wheel and container validation as pending integrated CI rather than claimed locally (audit/integrated-local-validation.json), and the browser, GUI, IDE and mobile wrappers are outside the v3 tests.

Possible improvements

_{Fig. 16 — Each line targets a qualification this repository states. None is claimed as started.}

• A version anchor against whole-file replay. Storing the latest committed revision somewhere the vault directory cannot roll back, and refusing an older revision on unlock, would close the replay gap the release notes describe.
• Operation-scoped tokens. Tokens limited to named operations would let each agent call only its own subset instead of the whole configured set.
• Measured side-channel hardening. Optional status bucketing and fixed-latency responses could be measured against a hostile synthetic endpoint, reported as a measurement rather than a guarantee.
• The independent crypto review. ROADMAP.md lists an independent review of the vault format and Argon2id parameters as open; publishing its findings next to the release evidence would answer it [8].
• One wrapper at a time. Porting a single historical wrapper to format v2, with its own threat model and tests, would move it from historical to validated without implying anything about the others.

Future work

_{Fig. 17 — Released items from CHANGELOG.md; open items as named, unchecked, in ROADMAP.md.}

Released, according to CHANGELOG.md:

1. The browser extension (2026-04-19 .. 2026-04-24) and enigmagent-mcp 1.0.x on npm (2026-04-24 .. 2026-04-25).
2. The bundled gateway 2.0.0 (2026-09-17): bearer authentication on REST, raw resolution off by default.
3. The integrated 3.0.0 release (2026-09-17): authenticated format v2, the fixed-operation broker, ten native framework adapters and the source-pinned container.

Open, as named in ROADMAP.md (written for the browser-extension milestones, so these are its wording, not v3 commitments): an independent crypto review of the vault format and Argon2id parameters (M2), a local audit log of every resolve that stores a hash of the value rather than the value (M3), and WebAuthn or a hardware key as a second unlock factor (M6).

Proposed next steps (not commitments). These are suggestions from this README build, not the author's published plan: a revision anchor against whole-file replay; operation-scoped broker tokens; a measured side-channel experiment against a hostile synthetic endpoint; and a format-v2 port of one historical wrapper with its own tests.

Contributing and citation

See CONTRIBUTING.md, CITATION.cff and the integration plan. Contributions must solve a real integration need and include reproducible evidence. Do not mass-post issues, request artificial engagement or re-contact maintainers who declined a proposal.

MIT License. Copyright 2026 Francisco Angulo de Lafuente.

Bibliography

1. Saltzer, J.H., & Schroeder, M.D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308. https://doi.org/10.1109/PROC.1975.9939
2. Hardy, N. (1988). The Confused Deputy. ACM SIGOPS Operating Systems Review, 22(4), 36–38. https://doi.org/10.1145/54289.871709
3. Rogaway, P. (2002). Authenticated-encryption with associated-data. Proceedings of the 9th ACM conference on Computer and communications security, 98–107. https://doi.org/10.1145/586110.586125
4. McGrew, D. A., & Viega, J. (2004). The Security and Performance of the Galois/Counter Mode (GCM) of Operation. Lecture Notes in Computer Science, 343–355. https://doi.org/10.1007/978-3-540-30556-9_27
5. Dworkin, M. (2007). Recommendation for block cipher modes of operation: Galois/Counter Mode (GCM) and GMAC (NIST SP 800-38D). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-38D
6. McGrew, D. (2008). An Interface and Algorithms for Authenticated Encryption. RFC Editor. https://doi.org/10.17487/RFC5116
7. Biryukov, A., Dinu, D., & Khovratovich, D. (2016). Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications. 2016 IEEE European Symposium on Security and Privacy (EuroS&P), 292–302. https://doi.org/10.1109/EuroSP.2016.31
8. Biryukov, A., Dinu, D., Khovratovich, D., & Josefsson, S. (2021). Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. RFC Editor. https://doi.org/10.17487/RFC9106
9. Cotton, M., Vegoda, L., & Haberman, B. (2013). Special-Purpose IP Address Registries. RFC Editor. https://doi.org/10.17487/RFC6890
10. Jones, M., & Hardt, D. (2012). The OAuth 2.0 Authorization Framework: Bearer Token Usage. RFC Editor. https://doi.org/10.17487/RFC6750
11. Greshake, K., Abdelnabi, S., Mishra, S., et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv 2302.12173. https://arxiv.org/abs/2302.12173
12. Debenedetti, E., Zhang, J., Balunović, M., et al. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv 2406.13352. https://arxiv.org/abs/2406.13352
13. Debenedetti, E., Shumailov, I., Fan, T., et al. (2025). Defeating Prompt Injections by Design. arXiv 2503.18813. https://arxiv.org/abs/2503.18813
14. Beurer-Kellner, L., Buesser, B., Creţu, A., et al. (2025). Design Patterns for Securing LLM Agents against Prompt Injections. arXiv 2506.08837. https://arxiv.org/abs/2506.08837
15. OWASP Foundation (2025). OWASP Top 10 for Large Language Model Applications. OWASP Foundation. https://owasp.org/www-project-top-10-for-large-language-model-applications/
16. Anthropic (2025). Model Context Protocol specification, revision 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18
17. Angulo de Lafuente, F. (2026). PayPal Agentic Guardrail: a payment operation broker that keeps the credential, the payee and the amount ceiling out of the agent's hands. GitHub. https://github.com/Agnuxo1/paypal-agentic-guardrail

---