Securing homegrown agents built with LangChain, LangGraph, CrewAI, or your own framework

Framework convenience can hide security ownership

LangChain, LangGraph, CrewAI, and custom orchestration make it straightforward to give a model tools, memory, retries, and multi-step plans. That speeds development, but the framework cannot decide how much potential damage your organization will accept. It does not know which customer table is sensitive, which environment is production, or which outbound message carries legal consequence.

The security boundary lives where model-selected intent becomes a side effect. If a tool wrapper accepts arbitrary SQL, shell, URLs, paths, recipients, or cloud operations, the model effectively inherits the authority behind that wrapper. Framework-level tracing helps explain behavior after the fact. Prevention requires a decision before the side effect.

Separate planning identity from execution authority

Do not place broad credentials directly in the agent process and hope the prompt will constrain their use. Give tools narrow service identities or delegated tokens with the smallest scopes and lifetime that support the task. Keep production and test identities separate. Make the executor validate the target environment rather than trusting a model-generated label.

For employee-facing agents, decide whether the agent acts as the user, as a dedicated agent identity, or as a service. Each choice changes accountability and access. NIST and Microsoft are both focusing on agent identity because a nonhuman operator needs discoverability, authorization, ownership, and lifecycle controls beyond a generic API key.

Design tools as security APIs

A safe tool has a narrow purpose, typed arguments, server-side authorization, predictable effects, and a useful audit record. Prefer createDraftInvoice over executeArbitraryERPRequest. Prefer queryCustomerSummary over runSQL. If general tools are unavoidable, validate paths, commands, destinations, methods, and resource limits outside the model.

Add idempotency to operations that may retry. Agents repeat tool calls after timeouts, partial failures, or confusing output. A safe system should not send the same customer email, create the same order, or charge the same card twice because the planner did not receive a clean response.

• Use schemas that make dangerous arguments explicit and reject unknown fields
• Authorize on the server using trusted identity and resource context
• Return structured results that separate data from instructions
• Set time, token, tool-call, cost, and concurrency budgets
• Require idempotency keys for operations with financial or external side effects
• Record the proposed action, decision, final result, and one reference that ties the steps together

Memory is both data and future instruction

Agent memory can contain customer data, tool output, summaries, preferences, and prior instructions. A poisoned item may influence future sessions long after the original source disappears. Apply data classification, retention, tenant isolation, and provenance to memory. Do not let the model decide by itself which secrets should become durable memory.

Treat retrieved memory as untrusted content. Preserve the source and time. Limit the actions a memory item can influence. A sentence retrieved from a ticket, webpage, or shared document should not silently override policy or authorize a tool call.

Human-in-the-loop needs persistence

LangChain documents human-in-the-loop middleware that can interrupt matching tool calls, save state, and resume after approve, edit, or reject. That pattern is important. A review should be a durable workflow state, not a process waiting forever on a terminal session. The action must not execute while the system is unsure whether approval arrived.

Bind every answer to the exact request. Show the complete action, the policy reason, when the request expires, and the available choices. Never send one approval to every agent session or accept a generic yes that could approve the wrong action.

Protecting a homegrown agent with Leash

Connect the agent to Leash before it is allowed to make real changes. Leash evaluates the action with enabled protections, records the outcome, and returns a clear decision. The agent must honor that decision, while the connected service should still enforce its own permissions.

Personal Open Source is best for agents running on the same computer. Leash Cloud is the easier choice for agents running online or across several devices. When a platform only shares activity after completion, Leash can add visibility and evidence, but it cannot undo a completed action.

Production readiness review

Before launch, enumerate tools and prove the policy for each high-impact operation. Test prompt injection through user input, retrieved documents, tool output, and memory. Simulate retries, partial failures, timeouts, duplicate events, revoked credentials, unavailable policy services, and a reviewer who never responds.

The right failure mode depends on consequence. A summary can degrade gracefully. A payment, deletion, release, identity change, or external communication should fail closed with a clear diagnostic. Production readiness means the system remains understandable when the model, tool, network, or human behaves unexpectedly.