Protecting credentials in job automation

The moment an automation signs into a job board as the candidate, you hold credentials for third-party services belonging to your users. Many teams arrive at this without deciding to, by adding a convenience feature.

That makes you a target with obligations: breach notification, a credible story about storage, and a plan for revocation. It is worth acknowledging explicitly before the architecture calcifies, because retrofitting is much harder than designing for it.

The blast radius is wider than your product. People reuse passwords, so a credential store for job boards is in practice a partial credential store for email and banking too, and the consequence of a breach is not confined to the service you were automating.

The strongest position is having nothing worth stealing. Where a service supports OAuth or an API token, use it — a scoped, revocable token is categorically better than a password, because it grants less and can be withdrawn without the user changing anything.

Where only a password works, consider whether the feature is worth it. "We sign in as you" is a significant liability for a convenience that saves a candidate one login, and a browser extension running under the user’s own session avoids the storage problem entirely.

Session handoff is the middle option worth designing for. The user signs in themselves and your system receives only a session, which is sensitive but expiring, scoped and not reusable against anything else they own.

• OAuth or scoped tokens wherever the service offers them
• A user-side extension acting under their own session
• Session handoff, where only a browser flow exists
• Storage only where none of those is possible, and only with encryption
• Never a shared credential across multiple users

Encrypting at rest is the obvious step and the easiest to get superficially right. Use a dedicated key management service, encrypt per user rather than with one application-wide key, and keep the key out of the same store as the data.

The subtler problem is that the credential must be decrypted to be used, so it exists in memory, possibly in logs, possibly in an error report sent to a third-party monitoring service. Those paths leak far more often than databases do.

Browser automation adds two of its own. A failure screenshot taken on a login page can capture an unmasked password field, and a full request trace can contain the submitted form body — both written automatically into artefact stores that nobody scoped as sensitive.

Audit the leak paths as deliberately as the storage. Log redaction, error-reporting scrubbing, screenshot policy on authentication pages and what a trace records are four checks that take an afternoon and cover the ways this actually goes wrong.

A credential must never enter a prompt. Not in the context, not in a tool result, not in an error message the agent reads — because prompts get logged, sent to a provider, and sometimes reflected back in output.

The pattern that works: the agent asks for an action, and your code performs the authenticated part. The agent invokes `submit_application(job_id)`; your server holds the session and does the signing in. The agent never sees a secret, so no amount of persuasion extracts one.

This matters more than usual because the agent reads text written by strangers. A job posting can contain instructions aimed at it, and the only defence that holds is the agent having nothing to disclose — a prompt rule telling it to keep secrets is not a boundary.

Users must be able to see what is stored and remove it immediately, with the deletion actually propagating — including to any cached session, background worker or queued job holding a copy.

Build a kill switch too: one action that invalidates every stored credential for a user, for the case where their account is compromised. It is rarely needed and impossible to improvise under pressure, which is exactly why it belongs in the design rather than the backlog.

Record every use, and show it to them. A candidate who can see which service was accessed, when, and for what is a candidate who can spot something wrong — and that log is also the only way to answer the question honestly if they ask.

Set an expiry on what you hold. A stored credential for a search that ended four months ago is pure liability, so prompting to reconnect after a period of inactivity costs a click and removes a standing risk nobody is watching.