security

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Limit permissions principle of least privilege

When building applications with LangChain integrations, scope permissions specifically to the application's needs. Granting broad or excessive permissions introduces significant security vulnerabilities. Use read-only credentials, disallow access to sensitive resources, use sandboxing techniques such as running inside a container, and specify proxy configurations to control external requests as appropriate for your application.

Anticipate potential LLM misuse

Always assume that any system access or credentials may be used in any way allowed by the permissions they are assigned. For example, if database credentials allow deleting data, assume that any LLM able to use those credentials may in fact delete data. Do not rely on LLMs to self-limit their actions.

Defense in depth security approach

No single security technique is perfect. Fine-tuning and good chain design can reduce, but not eliminate, the odds that an LLM may make a mistake. Combine multiple layered security approaches rather than relying on any single layer of defense. For example, use both read-only permissions and sandboxing to ensure that LLMs are only able to access data explicitly meant for them to use.

Risks of inadequate security in agent applications

Risks of not following security best practices in applications with external resource access include: data corruption or loss, unauthorized access to confidential information, and compromised performance or availability of critical resources.

File system agent security mitigation

A user may ask an agent with access to the file system to delete files that should not be deleted or read the content of files containing sensitive information. To mitigate, limit the agent to only use a specific directory and only allow it to read or write files that are safe to read or write. Consider further sandboxing the agent by running it in a container.

API agent security mitigation

A user may ask an agent with write access to an external API to write malicious data to the API, or delete data from that API. To mitigate, give the agent read-only API keys, or limit it to only use endpoints that are already resistant to such misuse.

Database agent security mitigation

A user may ask an agent with access to a database to drop a table or mutate the schema. To mitigate, scope the credentials to only the tables that the agent needs to access and consider issuing READ-ONLY credentials.

Bug bounty eligible packages

Bug bounties are offered for vulnerabilities in: core libraries owned and maintained by the LangChain team including langchain-core, langchain (v1), langgraph, and related checkpointer packages or their JavaScript equivalents; and popular integrations maintained by the LangChain team such as langchain-openai, langchain-anthropic, etc., or their JavaScript equivalents. The vulnerability must be in the library code itself, not in example code or example applications.

Out-of-scope security report targets

The following are out-of-scope for security vulnerability reports: langchain-experimental archived repository for experimental code; examples and example applications; code documented with security notices decided on a case-by-case basis; and LangSmith related repositories or APIs which should be reported separately.

Reporting OSS vulnerabilities process

To report security vulnerabilities in LangChain open source projects: submit a security advisory on the Security tab in the GitHub repository where the vulnerability exists, and send an email to security@langchain.dev notifying of the filed security issue and which repository it was filed in.

Reporting LangSmith vulnerabilities

To report security vulnerabilities associated with LangSmith, send an email to security@langchain.dev. Do not use the standard GitHub security advisory process for LangSmith issues.

Slack channel security and deployment limits

Managed Deep Agents verifies every Slack request against its raw body and rejects signatures outside Slack's five-minute replay window. Slack Connect shared conversations are not supported. `runtime.channel` does not expose `SLACK_BOT_TOKEN` or other provider credentials. Event deduplication is currently process-local, so a multi-replica deployment can invoke the agent more than once when Slack retries an event. Channel-triggered tools should be designed as idempotent when they perform external side effects, as Slack retries and multi-replica processing can produce more than one run for the same logical event.

Custom encryption for sensitive data

The Agent Server supports custom encryption via LANGGRAPH_AES_KEY for checkpoint blobs and writes, with AES encryption implemented in the Go checkpointer. LANGGRAPH_AES_JSON_KEYS configuration enables AES encryption for specified JSON fields using a key name allowlist. Custom encryption middleware can be applied to encrypt selected payload fields (values, interrupts, errors, thread config, etc.), with system fields excluded from encryption to prevent unnecessary overhead.

License verification and resilience

License check resilience includes cached fallback, 24-hour grace period, and automatic cleanup of Redis entries during upstream outages. LANGSMITH_CONTROL_PLANE_API_KEY is used for license verification in hybrid deployments. License claims enforcement allows remote disabling of specific products for self-hosted Enterprise users.

Give your agent this brain