We provide managed hosting and website maintenance at ResaHost, and we set up and manage 1Password Business for customers, so we have a commercial interest in how teams handle secrets. This article uses 1Password only as one documented example, and the principles apply to any secrets manager.

The risk is not only a bad model, it is untrusted input

OWASP's LLM01 entry on prompt injection describes indirect prompt injection: the model accepts input from external sources such as websites or files, and that content alters its behaviour. OWASP lists disclosure of sensitive information, unauthorised access to functions available to the model and executing arbitrary commands in connected systems among the possible outcomes. It also states that it is unclear whether fool-proof prevention exists, and recommends limiting the impact instead.

For a developer this means a README, an issue comment, a dependency's documentation or a web page the agent fetches can contain text meant for the agent. You cannot rely on reading every input yourself. The design question becomes: if the agent follows a hostile instruction, what can it reach?

OWASP's mitigations map directly onto that question. They include enforcing privilege control and least privilege access, requiring human approval for high-risk actions, and segregating untrusted external content from instructions.

Principle 1: the agent should not hold more than the task needs

The OWASP Secrets Management Cheat Sheet notes that many organisations hard-code secrets in source or leave them in configuration files, and recommends centralising storage, provisioning, auditing and rotation. It also says engineers should not have access to all secrets in the system, and that fine-grained access control should apply least privilege.

For an agent session, apply the same rule:

• Use a separate, low-privilege credential for the agent, not your personal admin token.
• Do not give it production credentials unless the task is a production task.
• Prefer credentials that are limited to one repository, one environment or one API scope.

Principle 2: short-lived beats long-lived

OWASP recommends dynamic secrets where possible, with a short lease and revocation when they are no longer needed, and automated rotation for static secrets. An API key that expires after an hour is worth much less to anyone who extracts it than a key that lives for years. If your provider supports scoped, expiring tokens, use them for agent sessions.

Principle 3: keep secrets off disk and out of history

Plaintext .env files get committed, copied, backed up and read by whatever runs in the directory. Two documented ways to reduce that:

1. Secret references. With the 1Password CLI, you store a reference such as op://vault/item/field in your configuration instead of the secret. op run replaces the reference with the real value only for the subprocess it starts. The documentation recommends service accounts that are restricted to specific vaults, so processes in the session can only access the items needed.
2. An SSH agent. The 1Password SSH agent lets Git and SSH clients authenticate without being able to read the private key, and only clients you explicitly authorise can use the key until 1Password locks.

Be precise about what this achieves. Secret references keep the value out of files and shell history. They do not make the value invisible to a process you start with them. A subprocess that receives a secret as an environment variable can print it, and an agent that can run arbitrary commands in that environment can be asked to. So the second half of the defence is scope: the vault or service account behind the reference should contain only what that session needs.

Principle 4: catch what leaks anyway

Mistakes happen, so add detection. OWASP suggests secrets detection at developer level, in the IDE or through a pre-commit hook, so secrets are not committed. On the repository side, GitHub secret scanning detects credentials committed to repositories, and push protection is a related feature. When a secret is exposed, rotate or revoke it. OWASP is explicit that removing it from the exposed system is part of the response.

Principle 5: keep a human at the risky steps

Do not run an agent in an auto-approve mode with broad credentials. Require review of the diff before a commit lands, and approval before the agent runs commands that touch deployment, billing, DNS or credentials. If an agent suddenly asks for access to something the task does not need, stop the session and look at what it read before that point. This is the OWASP recommendation of human approval for high-risk actions, applied to a terminal.

Also keep an audit trail. OWASP lists what to log at a minimum: who requested a secret and for which system, whether the request was approved, when it was used, and when it expired.

A starting checklist

1. Move every long-lived key out of .env files and into a secrets manager.
2. Create a dedicated, scoped credential for agent sessions.
3. Turn on secret scanning and push protection for your repositories.
4. Keep production credentials out of agent sessions by default.
5. Review diffs before commits, and require approval for high-risk commands.
6. Rotate any key an agent session may have seen.

We list eight related controls for terminal-based coding in our article on AI-assisted coding in the terminal. The ones above are the part that concerns secrets, and each rests on a public source.

Sources

1. OWASP GenAI: LLM01 Prompt Injection
2. OWASP Secrets Management Cheat Sheet
3. 1Password Developer: Use secret references with 1Password CLI
4. 1Password Developer: 1Password SSH Agent
5. GitHub Docs: About secret scanning
6. ResaHost: AI-assisted coding in the terminal (commercial source)

We provide managed hosting and website maintenance at ResaHost, and we set up and manage 1Password Business for customers, so we have a commercial interest in this subject. The steps below are not specific to one product, and where we describe product behaviour we link the vendor's own documentation.

Why reuse is the problem to solve

The attack to design against is credential stuffing: the OWASP Credential Stuffing Prevention Cheat Sheet defines it as testing username and password pairs obtained from the breach of another site. If an employee uses the same password for a supplier portal and for the company mailbox, the portal's breach becomes your incident. OWASP names multi-factor authentication as by far the best defence against password attacks of this kind, so a password manager and MFA belong together.

The UK NCSC gives the same reasoning for a unique password per account, notes that nobody can remember that many, and recommends turning on two-step verification on the password manager account as well. NIST's authentication guideline, SP 800-63B, goes further for service owners: verifiers shall allow password managers and autofill, and should permit pasting into password fields. If you run a login form for your own product, blocking paste works against your users' security.

1. Inventory where the logins live today

List the services your team signs in to, and for each one note where the login is kept and who uses it. Developers and site owners should include the less obvious ones: domain registrar, DNS provider, hosting control panel, SSH and database credentials, payment and analytics accounts, and the shared inbox that receives password resets. Mark the email accounts used to reset other passwords. Whoever controls those can usually reach everything else.

2. Decide on vaults and two administrators

Keep the vault structure small. A shared vault for logins everyone uses, one for finance, and one for website, domain and infrastructure access is enough for a small company. Vaults should follow who needs to see what, not mirror a list of services.

Name at least two administrators. If the only administrator is away or leaves, nobody can add users or recover a locked-out account. Check how recovery works in the product you pick before you rely on it.

3. Understand what protects the vault

With 1Password, for example, the data is encrypted with a key derived from two things: the account password and a Secret Key. According to 1Password's documentation, the Secret Key has 128 bits of entropy and is stored on the user's devices and in the Emergency Kit rather than with the vendor, and the account password, which has to be memorised, has about 40 bits of entropy on average. Those two figures explain why the account password still has to be long and unique, and why losing the Secret Key without a saved Emergency Kit can lock you out. Other products design this differently, so read the vendor's security model before you decide.

4. Move the logins, then delete the old copies

Import from browsers or spreadsheets, check the result, and then remove the originals. If you skip the deletion step, the logins live in two places again, which is worse than before because nobody knows which copy is current. A browser export is an unencrypted file, so delete it, including from the trash, as soon as the import is verified.

5. Replace the reused and weak passwords

Moving a weak password into a vault only stores it neatly. Work through the manager's warnings for reused, weak and breached passwords in order of importance: email first, then the domain registrar, bank, accounting, cloud storage and the website admin. Generate random replacements and turn on MFA at the same time where the service supports it. The NCSC also recommends passkeys as the first choice wherever a service offers them, with a unique password plus two-step verification elsewhere.

This step does not have to happen in one day. Agree who handles the list and by when.

6. Share with outsiders through the manager

Accountants, freelancers and stand-in staff sometimes need a login. Sending it by email or text puts a secret in two mailboxes with no expiry. Many business password managers can share an item with a time limit or give a guest access to a single vault. Use that and review it when the engagement ends.

7. Write the leaver checklist

Removing a departing employee's account is not enough, because they may have seen or copied shared passwords. Because the logins now sit in vaults, you can list which vaults they could open and rotate the most important credentials in those vaults. Without a password manager that list usually does not exist, which is why old shared passwords stay in use for years.

When to ask for help

A ten-person company can do all of this itself if someone has the time. We describe the same rollout, step by step, in our guide to rolling out a password manager in a small business. It is written around 1Password Business because that is the product we deliver, and we say so there as well.

Sources

1. OWASP: Credential Stuffing Prevention Cheat Sheet
2. UK NCSC: Password managers
3. NIST SP 800-63B: Authentication and Authenticator Management
4. 1Password Support: About your Secret Key
5. ResaHost guide: Rolling out a password manager in a small business (commercial source)

We provide managed hosting and website maintenance at ResaHost, so we have a commercial interest in this subject. We also produced the research discussed here. Our sample came from our own analysis service, not a random survey of Finnish businesses. It cannot tell us how common these issues are across the country.

We used reports stored between 12 August and 10 September 2026 and selected the latest retained report for each domain. Stored time is not necessarily measurement time. Of those reports, 128 contained eligible structured diagnostics. We cannot establish the number of separate companies from these records. We did not independently recheck the original measurements through the published aggregate.

We kept a separate denominator for each check. We did not count missing diagnostics as missing protection, and we do not add overlapping groups or percentages together. We did not investigate actual break-ins, fraud losses or whether a specific weakness had been exploited. These findings do not establish a legal violation.

We start with what the test actually observed

We found no DMARC record at the queried DNS name for 51 of 85 eligible email domains. Another 22 used p=none. Together, 73 of those same 85 domains had no record found at that name or a policy requesting neither quarantine nor rejection. We keep that combined count within its original eligible group.

We do not interpret those observations as proof that a fraudulent invoice would reach someone’s inbox. Recipient filtering and a policy inherited from a parent domain can affect the result. Our statistical analysis did not verify those factors.

We would turn the finding into a practical question: which systems legitimately send email for this domain, and who checks their authentication? That includes billing software and marketing platforms, not just the everyday mailbox. We would review the legitimate senders before tightening the policy. The UK NCSC recommends introducing DMARC gradually, starting with a monitoring phase.

We separate an old version from a confirmed vulnerability

We observed at least one publicly detected plugin version older than its WordPress.org comparison version on 46 of 73 eligible websites. We identified versions from public files or resource information. We did not sign in to verify the installed plugin inventory. A public version string may not describe the installation accurately, so we would confirm it before deciding what to change.

We therefore treat this as a maintenance lead, not a vulnerability finding. A newer release may contain a security fix, a feature change or both. We would verify the installed version, review the release information and known issues, then plan the update with a backup and a functional check.

We distinguish a missing header from browser behaviour

We found HSTS absent from 84 of 127 saved HTTP responses eligible for this check. Those records had saved headers and an HTTP status from 200 to 399. We describe the response that was recorded, not every connection a visitor might make or every way a browser might enforce HTTPS.

We would not turn that count into a claim that 84 websites left their visitors unprotected. A previously stored HSTS policy, a parent-domain policy covering subdomains or a preload entry can affect the browser’s behaviour. We would check the actual hostname and applicable policies before choosing a change.

We would also review subdomains before extending a policy to them. A setting that enforces HTTPS needs to match the services people actually use. We would verify the intended behaviour rather than adding a header simply to improve a report’s appearance.

We turn the report into an owner and a next action

We would record each observation in a short work list: what we saw, what still needs verification, who owns the check and how we will confirm the result. For email, that might mean reviewing senders and authentication reports. For WordPress, it might mean verifying plugin versions and testing an update.

We would also record uncertainty. A missing result is not automatically a missing control. A clean-looking page is not evidence that its underlying software is maintained. Neither a red indicator nor a green one should replace a discussion with the responsible administrator.

We published the full counts and methodology in our research article, now available in English and linked below. The Finnish version describes the same study, not a second dataset. We use these observations as a technical starting point, not a penetration test, a legal compliance assessment or a promise that a website is safe.

Sources

1. Our research: counts, methodology and limitations · English · commercial source
2. Published aggregate counts and calculation notes · Finnish
3. UK NCSC: implement a DMARC policy of none
4. MDN: Strict-Transport-Security