Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Forum Discussion
reremaru
1 hour agoNew Contributor
AWS Secrets Manager integration: destination won't persist, zero API calls reaching AWS
Hi all,
Looking for help / similar reports on the AWS Secrets Manager
(Environments) integration. Our sync has completely stopped working and
re-creating the integration does not bring it back. A support ticket is
already filed; posting here in case anyone has hit the same and found a
faster fix.
## Symptoms
- Changes in 1Password Environments (additions, edits, deletions of any
variable) do **not** propagate to AWS Secrets Manager.
- The integration card in the 1Password UI stays in the unconfigured
"Configure destination" state. There is no "connected" / "ready"
indicator, just the configuration prompt.
- This affects **all environments** simultaneously, not just one.
- The "Configure destination" save action visually succeeds with no
error, but immediately reverts the screen back to the unset
"Configure destination" state. Re-entering and saving multiple times
produces the same revert. The destination is never persisted.
- Recreating the integration (deleting and setting it up again, even
with a brand new target secret name) does not restore sync. The new
target secret is also never written to.
- This was working previously; the last successful sync (visible in AWS
as the secret's `LastChangedDate`) was 25 days before the issue began,
and the freeze started without any change on our side.
## Environment
- 1Password plan: Individual
- 1Password Desktop App: 8.12.12 (Windows, latest)
- AWS region: us-east-1
## What we've verified on the AWS side
- AWS CloudTrail (`lookup-events` filtered by the target secret's
resource name) shows **zero `UpdateSecret` / `PutSecretValue` events**
in the past 24 hours from any principal — i.e., 1Password is not even
attempting an API call. There is no AccessDenied / ThrottlingException
either, just no request reaching AWS.
- IAM role / SAML provider used by the integration still exists with
unchanged trust policy and `secretsmanager:*` permissions on the target.
- KMS key is intact, no SCP changes in the org.
- Other AWS-bound integrations from our account work normally.
## Parallel fresh integration test
To rule out integration-specific corruption, we set up a completely new
parallel integration without deleting the existing one:
- New 1Password Environment (different name)
- New SAML Identity Provider in AWS (different name)
- New IAM Policy in AWS (different name, scoped to a new secret name
pattern)
- New IAM Role in AWS (different name, with `SAML:sub` trust condition
matching the SAML subject value provided in the 1Password
configuration page)
- New target secret name in 1Password's destination config
Result: **identical failure mode**.
- Clicking "Create integration" reverts the destination to unset, no
error shown. The integration card never moves out of the unconfigured
state.
- AWS CloudShell verification: zero matching secrets created, zero
`CreateSecret` events recorded across the entire account in the time
window of the parallel save attempts.
- A sanity-check `describe-secret` call against an unrelated existing
secret returns successfully, confirming our AWS CLI access is
functional.
This pattern (no API call at all, save action not persisted, parallel
fresh integration also broken) suggests an account-level issue on the
1Password side — possibly invalidated integration credentials, a stuck
sync worker, or a silent server-side validation failure preventing the
destination from being persisted. We can't diagnose further from the
AWS side.
## Questions
1. Has anyone else seen this — silent sync stop affecting all
environments simultaneously, with the save action visibly succeeding
but the destination never persisting?
2. Is there a way (CLI / SDK / admin console) to check the integration's
internal sync status / last-attempted-sync timestamp / error log on
the 1Password side?
3. Any way to force-trigger a sync attempt from outside the standard
"save in environment" path? Save-and-edit no longer triggers anything
reaching AWS.
We have already filed a support ticket. Posting here in case anyone has
hit the same and found a fix faster than support turnaround.
Thanks!
No RepliesBe the first to reply