DEV Community: Alizamin Jafarli

Stop Putting Secrets in Plaintext

Alizamin Jafarli — Mon, 24 Aug 2026 22:45:40 +0000

Most local dev setups end up with some secret — an API key, a cloud credential, a database password — sitting in a plaintext file on disk indefinitely. Here's a simple pattern that avoids that, using AWS credentials as the example.

The problem with the usual approaches

A credentials file (e.g. ~/.aws/credentials) — plaintext, no expiry, no prompt. Anyone with filesystem access (malware, a compromised dependency, a careless backup, a stolen unencrypted disk) reads it instantly.
A .env file "just for now" — inevitably ends up committed once someone forgets it's there, or pasted into a chat while debugging.
Secrets exported in your shell profile — same problem, just moved into .bashrc or .zshrc, still plaintext, still readable by anything running as your user.

The common thread: none of these require proving you're you at the moment of use. The secret just sits there, decrypted, waiting.

The fix: password manager + directory-scoped env loading

Store the secret in a system built for secrets — a password manager — and only materialize it into the environment for the duration of a shell session, gated behind your master password.

A password manager like Bitwarden gives you:

Encrypted-at-rest storage, synced across devices.
A CLI (bw get item, bw unlock --raw) that scripts easily.
A clean separation between login (proving identity to Bitwarden's servers) and unlock (decrypting the vault locally with the master password) — unlock is what gates access, and it's required every time.

direnv gives you:

Automatic loading/unloading of environment variables scoped to a directory. cd in, get the vars; cd out, they're gone.
A trust boundary: .envrc files must be explicitly approved (direnv allow) before they execute, so a malicious .envrc in a cloned repo can't silently run code.
No setup script to remember — it's automatic on directory entry.

Together: the secret never touches disk in plaintext. It lives encrypted in Bitwarden, and only exists as an environment variable for the lifetime of a shell session in one directory, after an explicit unlock.

Example: AWS credentials

Store the key as a normal Login item (or a secure note) in Bitwarden (e.g. named aws-iam-keys) with custom fields aws_access_key_id and aws_secret_access_key.

Then a project's .envrc:

BW_ITEM="aws-iam-keys"

export BW_SESSION="$(bw unlock --raw)"
item_json="$(bw get item "$BW_ITEM" --session "$BW_SESSION" 2>/dev/null)"

if [ -z "$item_json" ]; then
  log_error "Could not fetch Bitwarden item '$BW_ITEM'"
  return 1
fi

bw_field() {
  echo "$item_json" | jq -r --arg name "$1" '.fields[]? | select(.name == $name) | .value // empty'
}

export AWS_ACCESS_KEY_ID="$(bw_field aws_access_key_id)"
export AWS_SECRET_ACCESS_KEY="$(bw_field aws_secret_access_key)"

cd-ing into the project prompts for the Bitwarden master password once and exports the two env vars that any AWS SDK or CLI already knows how to read. The same pattern works for any secret: swap the item name and field names, export whatever env vars the tool in question expects (a database URL, an API token, whatever).

One thing worth noting: direnv only re-executes .envrc when the directory changes or the file itself is edited — it doesn't re-run on every command within the same shell. So "prompt once per shell/directory load" isn't something you have to build; it's just how direnv already works. It's tempting to cache the unlocked BW_SESSION to a file so multiple terminal tabs share one unlock, but that just trades one problem for another — now there's a live decryption key sitting on disk. Re-entering the master password once per new terminal is a fine trade for keeping no secret material on disk at all.

Takeaway

For any local secret, ask whether it's ever decrypted-and-idle on disk. A password manager + directory-scoped env loading means the secret only exists in memory, for as long as you're in the project, gated behind an explicit unlock — a small amount of setup for a meaningfully smaller attack surface than a credentials file that just sits there forever.

What's your setup for local secrets — do you rely on a cloud secrets manager instead, or something else entirely? Curious to hear in the comments.

Choosing the Right Agentic AI Framework on AWS

Alizamin Jafarli — Fri, 14 Aug 2026 23:40:55 +0000

Here are three simple, architectural rules of thumb to help you choose the right path, along with a look at how to bridge the gap between custom local code and secure cloud production.

Rule 1: Lean on Configuration First, Code Second

Before you write a single line of state-management code, ask yourself: Does my agent need custom orchestration logic, or can it be defined by instructions and schema-driven tools?

If you want a fully managed experience where the cloud provider handles the underlying infrastructure, scaling, and orchestrating loop, Amazon Bedrock Agents is your starting point.

With Bedrock Agents, developer effort is shifted from writing boilerplate orchestrators to configuring action groups and integrating knowledge bases. You define the agent's instructions, hook up your APIs, attach your guardrails, and let Bedrock coordinate the reasoning loops behind the scenes. It has a low learning curve and requires zero infrastructure provisioning, making it ideal for teams that want production-ready capabilities without a massive development overhead.

When to use it:

You need to deploy rapidly using a configuration-driven approach.
Your agent primarily interacts with enterprise knowledge bases and standard REST APIs.
You do not have the in-house resources to manage custom containerized orchestrators.

Rule 2: Match the Framework to the State Machine

If a managed configuration is too restrictive and you need to write custom code, your next decision is about how your agents should coordinate.

For Deep AWS-Native Integration: Strands Agents

If your organization is heavily invested in AWS and you want custom code that integrates natively with the cloud ecosystem, Strands Agents is a premier choice. It offers the strongest AWS integration along with excellent support for foundation models like Anthropic Claude and Amazon Nova. It balances powerful autonomous workflow capabilities with moderate learning curves, making it an excellent default for enterprise-scale developers on AWS.

For High State Complexity: LangGraph

If your application requires a highly complex, custom state machine with cyclical loops, branching logic, and precise control over the conversation flow, LangGraph (and LangChain) is the gold standard. It is unmatched in workflow complexity and multimodal support, though it comes with a steep learning curve.

For Role-Based Collaboration: CrewAI

If your project depends on role-playing, where multiple specialized agents (like a researcher, a writer, and a code reviewer) must collaborate asynchronously to execute a sequential pipeline of tasks, CrewAI is a natural fit. It simplifies team-oriented architectures, allowing you to orchestrate collaborative agent "crews" with clear roles.

Rule 3: The Host Matters as Much as the Framework

A common mistake is assuming that choosing an open-source framework like CrewAI or LangGraph means you have to build, scale, and secure your own hosting infrastructure from scratch.

This is where Amazon Bedrock AgentCore enters the picture. Think of AgentCore as the production bridge. It is an agentic platform designed to host, secure, and operate agents built on any framework—whether it is LlamaIndex, CrewAI, LangGraph, or custom code.

AgentCore eliminates the undifferentiated heavy lifting of managing agent infrastructure. It provides several modular, serverless services that you can use together or independently:

AgentCore Runtime: A secure, isolated, and scalable serverless environment to run your custom agent containers without managing servers.
AgentCore Memory: A managed memory system that handles short-term and long-term context retention so your agents can build personalized, coherent conversations over multiple sessions.
AgentCore Gateway: A secure service that converts standard enterprise APIs into Model Context Protocol (MCP) tools, making them instantly discoverable and usable by your agents.
AgentCore Identity: Assures compliance and security by assigning unique, verifiable identities to agents, enabling fine-grained access control to enterprise data.
AgentCore Observability: Real-time tracing and monitoring of agent execution paths, giving you deep visibility to audit reasoning and debug failures in production.

By choosing a custom framework for development and pairing it with Bedrock AgentCore for production deployment, you get the absolute best of both worlds: ultimate open-source flexibility combined with enterprise-grade security, scalability, and managed operations.

Summary: Your Decision Matrix

Use Amazon Bedrock Agents if you want a managed, configuration-based approach with minimal custom code and rapid deployment.
Use Strands Agents if you are writing custom code and require native, deep integration with the AWS cloud ecosystem.
Use LangGraph if your workflow demands highly complex, cyclic state-machine orchestration.
Use CrewAI if your application is best structured as a collaborative team of specialized, role-based agents.
Deploy your custom framework of choice using Amazon Bedrock AgentCore to run, secure, monitor, and scale it in production without operational overhead.