FR: Allow Environments to reference Vault Items

Hey Shad0w! I love this idea. Thank you for sharing! 
My apologies on the delayed response here. I'll pass your suggestion along to the team for consideration :)

I totally agree. In the meantime, you might like varlock - there is a 1Password plugin to pull data from both individual items and environments, and it will let you have a nice dev flow without writing anything to disk.

I 100% agree on this. I was baffled when I realized that this wasn’t possible already, without it I can barely see the use-case for environments at the moment. I’d want to use environments to expose groups of secrets for a given application or machine. As soon as there are overlapping uses of the same secret, using an environment is moot, since the whole point of a password & secret manager is that I don’t have to manually keep secrets in sync.

I wish we had programmatic write / management access to environements, then we could build our own automation for this. A service account and a per-environment key-to-secret-ref mapping file would suffice to keep things in sync as a workaround, but as of right now we only have read-only access to environments.

Only the MCP seems to have write access for some reason, but it doesn’t seem to be able to delete environments or variables.

I absolutely love 1Password and recommend it to everyone due to its excellent embodiment of the union of security and convenience. This is actually the first time I am encountering such a big issue with it, and it’s only with an in-development beta feature. So please keep up the good work and I am excited to see progress on this.

I’d love if we could see full management capabilities for environments and 1Password secret mappings built-in soon, that would push this feature into an essential must-use for us :)

I joined the community after more than a decade just for this feature request! +1 please.

I was surprised to find that referencing vault items was not the default, please add this feature.

I’ll echo everyone else’s comments -- I was completely baffled by the fact that environments variables are entirely independent and that there’s no way to reference vault items.

+1 from a 1Password Business customer (50 seats, agency running CI/CD for many client projects).

We moved our pipelines to Environments and are testing Credential Broker with GitHub Actions OIDC. Both work well, but they only read from Environments, so every database password, API token and deploy key now lives twice: once as a vault item and once as an Environment variable.

That hurts us in three ways:

1. Rotation. Our automated rotation writes to vault items with `op item edit`, because service accounts only get Read access on Environments. The Environment copy goes stale until someone updates it by hand.

2. Audit. Item history, Watchtower and access reviews cover the vault item. The copy in the Environment that CI actually consumes sits outside that trail.

3. Scale. The same credential is often shared by several Environments (preprod and prod, several repos of one project). Each copy is another place to forget during an incident.

What we would like: when adding a variable to an Environment, let the value be either a plain string (as today) or a link to an item field, using the existing secret reference syntax, for example `DB_PASSWORD = op://Project-X/Database/password`. 1Password resolves it at read time for `op run --environment`, the local `.env` mount, Credential Broker and the AWS Secrets Manager sync. The Environment keeps its own access scope, so a workload that can read the Environment can resolve only the linked fields, not the whole vault.

That keeps the small blast radius that makes Environments attractive, and the vault item stays the single source of truth.