seekrit vs AWS Secrets Manager

Comparison·AWS Secrets Manager

AWS Secrets Manager is the default choice for a team already fully on AWS: no separate service to run, deep integration with the rest of the platform, and a compliance list few vendors can match. This page is about the two places it differs most from seekrit — who can decrypt, and who can call it at all.

If a credential in your AWS account is compromised, what does the attacker get?

Secrets Manager encrypts with envelope encryption: a KMS key wraps a per-secret data key, and every read calls KMS's Decrypt operation. With the AWS-managed default key, that call is scoped by a key policy that only permits Secrets Manager to invoke it on a principal's behalf. With a customer-managed key, you control the key policy and grants — a real, customer-held lever — but AWS KMS, a service AWS operates, still performs the decrypt. It isn't your own client doing the cryptography; it's AWS's infrastructure, gated by IAM and key policy rather than by a key only you hold. So the realistic breach question for Secrets Manager isn't "what if AWS itself is compromised" — that's not a scenario this page can usefully compare against anything — it's what does a compromised, sufficiently-privileged IAM principal inside your own account get, and the answer is: everything secretsmanager:GetSecretValue and kms:Decrypt let it reach. That's not hypothetical or slow. Anthropic's September 2026 threat intelligence report, covered in our post on three hours from one developer token to full cloud admin, recorded a single stolen developer token escalating to full administrative control of a cloud environment in about three hours — the realistic shape of this risk is an attacker racing your rotation schedule inside your own account, not a breach of AWS's own infrastructure.

If seekrit is breached: there's no privileged principal equivalent to steal, because no seekrit process holds a key able to decrypt more than one principal's own grant. Our security model states it at full strength and no stronger — secrets are encrypted client-side, and the server stores only ciphertext, wrapped keys, and metadata. A full compromise of our database, infrastructure, or staff yields ciphertext and the names of your secrets, not their values. Three honest boundaries: metadata is visible — names, versions, and timestamps aren't encrypted. Third-party sync is the one opt-in exception, scoped per environment. And the guarantee covers us being breached — a leaked seekrit service token still exposes whatever that principal held, same as a leaked IAM credential does for AWS.

The second difference is reach, not cryptography: Secrets Manager is reachable only by an AWS IAM principal. Their own docs describe the path for a non-AWS workload — IAM Roles Anywhere issues it temporary AWS credentials so it can call the API like any AWS caller. There's no path that doesn't end in "authenticate as AWS IAM." seekrit is a standalone service a browser, CLI, container, or CI job on any cloud talks to directly.

What that makes possible

No dynamic secrets outside a short AWS-native list. AWS's own definition of rotation is updating the stored value on a schedule, not minting a new, ephemeral, per-request credential. Built-in Lambda rotation templates exist only for RDS engines, DocumentDB, Redshift, Timestream for InfluxDB, ElastiCache, and Active Directory; anything else needs custom Lambda code. seekrit's temporary-access mints genuinely ephemeral, auto-expiring credentials for seven targets, including AWS itself over STS, with no Lambda to write.

An agent credential broker, which Secrets Manager has nothing resembling. Its features page describes IAM-gated retrieval and AWS-service integrations only. seekrit's egress proxy substitutes {{seekrit:NAME}} at the network boundary so the workload holding it never gets the real value.

Where AWS Secrets Manager is the better pick

You're fully on AWS, and that's worth a lot. Native resources in CloudFormation, IAM-role-based access from Lambda, ECS, and EKS via the Secrets Store CSI driver — one security model across everything you already run.

Compliance depth nobody else on this site matches. AWS's own compliance page for Secrets Manager lists HIPAA eligibility, PCI DSS Level 1, ISO 27001/27017/27018, SOC reports, FedRAMP, DoD Cloud Computing SRG, and regional programs.

Built-in cross-region replication, CloudTrail audit logging, and no separate vendor, bill, or login — billed per secret plus per API call.

Side by side

When AWS Secrets Manager is the right call

• Your workloads are already AWS IAM principals and you'd rather not add another vendor to the trust chain.
• You need FedRAMP, DoD SRG, or another compliance program AWS already covers.
• Your rotation needs are RDS/Redshift/DocumentDB-shaped — the built-in Lambda templates mean you write none of it.

When seekrit is the right call

• You're not fully on AWS, or not on AWS at all, and don't want every caller to have to become an IAM principal first.
• You need dynamic secrets outside AWS's native rotation list.
• An AI agent is the one holding the credential, and you want a broker that keeps the value out of its process, not just an IAM-scoped fetch.

The bottom line

AWS Secrets Manager is the right default if you're already inside AWS's IAM model and its compliance programs cover what you need. Its real exposure is the one every IAM-gated system shares: a compromised credential inside your own account reaches whatever that credential's policy reaches, fast. seekrit exists for everything that isn't that — infrastructure that spans clouds, a laptop, or an agent that shouldn't authenticate as an AWS principal just to get a value it shouldn't hold in the first place.

npx -y @seekrit/cli proxy run --preset openai

Free for one developer, no card, and no AWS account required.