Approval names exact secrets
A workload is enrolled for named secrets in a named project and environment. It cannot browse the store, guess at other secrets, or use another service’s permissions.
Workload secrets, released on current authority
Secrets go only to the workloads you named.
LatchHarbor holds your application secrets and hands them out one request at a time, only to the workload that was approved for them, only while that approval still stands, and never without a record of the decision.
No standing access to hand out and lose. If approval is withdrawn, new server requests are refused. A value the SDK already cached can be used only until its original short deadline.
Release clearancereq · illustration
- Workload
- billing-api / production
- Asking for
- payments signing key · current version
- Identity proof
- Enrolled key, verified
- Approval
- Named for this secret, still current
- Record
- Decision written before release
Released
The difference is when the check happens.
Approval can change after a workload signs in, so a login check alone is not enough. LatchHarbor checks again at the moment a secret is about to leave, against the authority as it stands right then.
Revocation blocks new releases
Withdraw approval and new server requests from that workload are refused. A secret the SDK already holds in cache may still be used until its original short deadline, and no longer.
A record is written before release
Each admitted release is recorded durably before plaintext is returned. The record shows who asked, what was approved, and when. It records the admission, not proof that the bytes arrived.
How a request is decided
Four things happen, in order, every time a workload asks for a secret. Failure at any point means refusal. There is no partial answer.
Prove who is asking
The workload presents the key it was enrolled with. A label or a network address is never treated as identity.
Name exactly what it needs
Requests list specific secrets. There is no “give me everything” mode for a workload to fall back on.
Check authority as it stands now
Enrollment, approval, version state and revocation are read fresh. A concurrent revocation that lands first wins.
Record, then release or refuse
For an admitted release, the record is committed before plaintext is returned. A refusal returns a plain denial that reveals nothing about what exists.
The record holds identifiers, versions and outcomes only. Secret values, tokens and credentials never enter logs or the audit trail.
When something goes wrong, the response follows a set plan.
Incident response fails when every step needs a fresh decision under pressure. LatchHarbor lets you pre-approve a containment plan for covered events, so the system can act on it deterministically, and it stops where the plan stops.
Containment follows the plan, not improvisation
For events covered in advance, LatchHarbor can carry out the exact preapproved actions, such as deleting or quarantining a named credential, through a separately authorized provider connection. An action counts as done only when the provider state shows the expected result. Anything outside the plan waits for a person.
Uncertain outcomes stay uncertain
If a provider call times out, LatchHarbor does not guess and does not blindly repeat it. The action is observed and checked against the provider’s own state first. A lost response may already have taken effect, and checking the result does not by itself authorize repeating the action.
Recovery cannot restore a revoked credential
Restoring service means issuing a new, verified credential. Containment is never “undone” by switching the exposed secret back on.
Limits, stated plainly
A secrets product earns trust by saying what it cannot do. These boundaries are part of the design, not fine print.
LatchHarbor does
- Check current authority in AWS before a new server release
- Write a durable, metadata-only record of each admitted release
- Keep AI and analytics on redacted, advisory information only
- Sign the status view it shares, so it can be read but never replayed as approval
- Run exact preapproved containment actions and check provider results before calling them done
LatchHarbor does not
- Recall plaintext once a workload has copied it. No system can do that.
- Let AI, queues or the metadata store grant access to a secret
- Treat a dashboard draft or a model suggestion as an approval
- Claim an incident action worked when the provider outcome is unknown
- Replace rotation and revocation duties at the downstream provider
Common questions
What happens when we revoke a workload’s access?
New server requests from that workload are refused. Authority is checked when a release is requested, so there is no token window to wait out. A value the SDK already cached can be used only until its original short deadline. Anything already copied stays copied, which is why the release record matters.
Does the AI assistant ever decide who gets a secret?
No. AI works from signed, metadata-only information and can explain activity or prepare a response for a person to approve. Access decisions are deterministic checks against AWS-held authority, and they keep working if the model is slow, unavailable or wrong.
Why not just use long-lived environment variables?
Because they can remain valid for a long time, are easy to copy, and often leave no record of who used them. LatchHarbor keeps the same basic flow. A workload asks and it receives, but each delivery is specific, checked and recorded, with bounded SDK reuse so services are not calling on every use.
If a provider call fails mid-incident, what then?
The outcome is recorded as unknown, not retried blind. LatchHarbor reads back the provider’s state to see what actually happened. Checking the result does not by itself authorize repeating the action, and manual steps stay labelled as manual. You can see which parts of containment are confirmed and which are still open.
Is LatchHarbor available to use today?
Not as a hosted service. The backend exists and is tested locally; live cloud verification is still ahead. This page describes the product as designed and built so far. Invited development accounts can sign in and open the workspace. This is not a live vault service.
the right workload, the named secret, checked at the moment of release, with the record to prove it.