Prompt injection in job agents

Most of what a job agent processes was written by a stranger with an interest in the outcome: job descriptions by employers and agencies, CVs by candidates, emails by recruiters and by people pretending to be recruiters.

It also holds capabilities worth attacking: it can send messages, submit forms, and it has access to personal data. Untrusted input plus meaningful capability is the exact precondition for indirect prompt injection, and job automation has both by design.

What makes it worse than most domains is that the untrusted content cannot be excluded. A job agent that refuses to read job descriptions has no function, so the usual advice to avoid processing hostile input does not apply here at all.

Each of these is content the agent must read to do its job, which is why none of them can simply be excluded.

The recruiter-side ones are worth particular attention. A screening agent reading CVs is processing documents from people who know it is automated and have a direct incentive to influence it.

The asymmetry matters too. Planting an instruction costs an attacker nothing and can be done long before any agent reads it, which means the attack is already in your corpus before you start looking for it.

• A job description containing instructions aimed at the agent reading it
• A CV with text sized or coloured to be invisible to a human reviewer
• A recruiter email instructing the agent to send information
• A careers page whose markup differs from what it renders
• A forged prior turn, where conversation history is supplied by the client

On the candidate side: exfiltrating a CV and personal details to an address of the attacker’s choosing, or suppressing applications to a competitor’s roles. On the employer side: promoting a CV past screening, or getting a competitor’s candidates rejected.

The damaging cases all require the agent to be able to *do* something — send, submit, write. An agent that can only read and present findings to a human has a much smaller attack surface, which is the single most useful design observation in this area.

Note that none of these require the attacker to touch your system. They write a document, someone else’s agent reads it, and the action happens with that user’s permissions — which removes most of the signals conventional monitoring relies on.

Filtering injection phrases helps against opportunistic attempts and will not stop a motivated attacker, because the ways to phrase an instruction are unbounded. Useful as a speed bump, wrong as a boundary.

What works is limiting capability. An agent with no send tool cannot be talked into sending. A submission that requires human confirmation cannot be triggered by a document. Credentials scoped to one candidate cannot reach another’s data however persuasive the text was.

Egress restriction is the control that most directly defeats exfiltration. If the agent can only reach the job boards and ATS domains it needs, an instruction telling it to send data elsewhere fails at the network layer regardless of how convinced the model was.

• Least privilege on every tool — most agents need far fewer than they are given
• Human confirmation on anything outbound or irreversible
• Untrusted text never merged into system instructions
• Client-supplied history replayed as user content, never as assistant turns
• Logging that ties each action back to the input that caused it

There is a temptation, widely discussed among job seekers, to plant hidden instructions in a CV aimed at whatever screens it. It is worth being clear that this is a bad idea for the person doing it rather than merely for the employer.

Screening systems increasingly extract structured fields rather than scoring raw text, so the instruction frequently has no effect. Where it is detected — and hidden white text is trivially detectable — it reads as deliberate deception, which ends the application and sometimes the relationship with that employer permanently.

If you are building a platform, this cuts both ways: detect it so employers are not deceived, and warn candidates who do it rather than silently rejecting them, because many have been told it is a legitimate tactic.

Put an injected instruction into a job description in your own test data and run the pipeline. Most teams discover their agent obeys it, and discover it for the first time in an environment where that is harmless.

Make this a standing test rather than a one-off. Injection resistance is not a property you achieve; it degrades whenever the prompt, the tools or the model change, so it belongs in the evaluation suite alongside quality.

Write the test to assert on the action rather than the text. Checking that the agent did not call the send tool is a reliable signal; checking that its response did not contain a suspicious phrase is not, because the same outcome can be reached many ways.