Your Job Postings Are an Attack Map. We Proved It.

Before the terminal opens

The first twenty minutes of an AI-targeted attack often happen in a browser, not a terminal. Before writing a single line of code, before touching a scanner, before running a single DNS query, a prepared attacker reads your job postings. Not because job postings are an obscure trick — they're a well-documented OSINT technique taught at every security awareness training that covers social engineering. But because the AI stack information disclosed in job descriptions in 2026 is qualitatively different from anything that appeared in postings three years ago.

A 2023 job posting might tell you a company uses AWS. A 2026 posting might tell you the role requires experience with GPT-4 and Claude over transaction data, orchestrated by LangChain with LangSmith observability, evaluated against Guardrails AI, running on Bedrock. Whether any of that reflects the current production system requires verification — but it is enough to know which questions to ask, which frameworks to assess, and which vendor relationships to look into. And it was written by a recruiter who had no idea anyone outside the talent team would read it this way.

This post documents the methodology — the same one security researchers use, and the same one PromptShield's scanner automates — and shows what the output looks like against a representative target. Then it covers what to do before the next role goes live.

What a job posting actually discloses

The PromptShield scanner fetches the target organisation's careers page, queries ATS platforms for open roles, and parses job description text for AI stack signals. The signals fall into five categories, each warranting a different type of follow-up investigation:

• Named model providers: 'experience with GPT-4', 'build on Claude', 'familiar with Gemini Pro' — suggests the organisation has or is evaluating a relationship with these vendors; warrants verifying which are in active production use, since role requirements reflect candidate criteria, not necessarily the deployed configuration
• Framework references: 'LangChain', 'LlamaIndex', 'CrewAI', 'AutoGen', 'LangGraph', 'Semantic Kernel' — indicates the organisation may be building on these frameworks; each has documented tool-calling interfaces and known security assessment patterns, so the framework name narrows what to look for when testing the deployed system
• Infrastructure signals: 'AWS Bedrock', 'Azure OpenAI', 'Google Vertex AI', 'Hugging Face Inference Endpoints' — suggests a likely cloud hosting environment; warrants verification of the actual deployment since infrastructure requirements in job postings may reflect aspirational or legacy context
• Data context clues: 'AI over our customer data', 'RAG pipeline on transaction records', 'real-time inference on account data' — indicates the data the AI role is expected to work with; actual data access controls and system boundaries require verification independent of the job description
• Tooling maturity signals: 'Guardrails AI preferred', 'LangSmith for observability', 'experience with Arize or Fiddler' — suggests possible use of these platforms or an intent to adopt them; 'preferred' language often indicates aspirational adoption, but deployment status requires direct confirmation

From a single careers page scan, a researcher can identify which vendors, frameworks, and data contexts are likely in play — all from information the organisation published voluntarily. Each signal requires follow-up to establish whether it reflects a deployed production system, an evaluation, or a candidate wishlist.

Scanner output — representative mid-size fintech

The callout above is a representative composite, constructed from signal patterns we regularly observe in real job postings — not a specific company's data. The point is not the specific signals; it's the structure. Five data points from a single job description, all voluntarily disclosed, all actionable. The organisation that posted this role almost certainly has a well-configured perimeter firewall, DMARC enforcement, and a WAF in front of its production systems. None of those controls are relevant to information extracted from a public job description.

Why 2026 job postings are a different threat

Job posting OSINT is not new. Security teams have known for years that technology stack disclosure in job descriptions is a reconnaissance signal. Mature organisations have long-standing policies about not naming specific security vendors in job postings — because naming your SIEM or your EDR tells an attacker which detection you have and which you don't.

The AI equivalent of this policy has not caught up. And the AI stack signals in job postings are more operationally specific than traditional technology stack disclosure for a reason: AI frameworks in common enterprise use have documented, framework-specific attack patterns that require knowing the framework before they apply. A generic LLM prompt injection payload is less targeted than one crafted for a specific framework's tool-calling interface. Knowing which framework is likely in use — from a job posting — is a lead worth following up, even though the posting alone doesn't confirm the deployed version, configuration, or security controls.

The vendor-tier signals add context worth examining. Anthropic's enterprise offering includes features like SSO and audit logging not available on consumer-tier API access. A job posting that references "integrating Claude via API" versus language that suggests an enterprise deployment is a signal — not a conclusion — about what logging and oversight infrastructure may be in place. That distinction is worth verifying, because the answer determines what audit trail exists for model interactions.

OpenAI's operator-level policy controls — which let enterprises configure permitted system prompt structures and tool access — mean that a job posting referencing "prompt engineering" alongside "OpenAI operator configuration" is a signal that custom system prompts may be in scope. This is a lead for investigating whether indirect prompt injection paths exist in that system, not a confirmation that system prompts are configured in a specific way.

LangSmith and the third-party observability gap

The LangSmith signal in the example above deserves its own paragraph, because it's not just a reconnaissance finding — it's a secondary target disclosure. LangSmith, LangFuse, Arize, and similar observability platforms receive prompt and response data from the AI systems they instrument. That data includes whatever the user typed into the AI, whatever the system retrieved from its knowledge base, and whatever the model returned — across every interaction.

When a job posting references one of these platforms, it raises two questions worth investigating: whether the organisation's AI prompts and outputs are flowing to a third-party vendor, and if so, whether that vendor's data retention and access policies have been reviewed. The finance team may never have invoiced for LangSmith — it's often billed to an engineering team's credit card as a developer tool — which means it may never have gone through procurement review, data processing agreement review, or the vendor risk assessment process. Verification is required before drawing conclusions; the job posting is the starting point, not the answer.

PromptShield's finops layer flags this pattern: observability platforms that appear in job postings but aren't in the approved vendor list are candidates for spend consolidation and data flow review. The job posting scan often reveals third-party AI data flows that the security and finance teams didn't know existed. This is the "AI for staff, spend, and security" problem in miniature — the signal exists, scattered across careers pages and engineering team credit card bills, but nobody has assembled it into a view the CISO can act on.

ISO 42001 and the disclosure policy gap

ISO/IEC 42001 — the AI management system standard — requires organisations to identify and document risks from their AI systems. Clause 6.1, covering AI risk identification, requires a systematic process for identifying risks arising from the organisation's AI context, including information security risks. Public disclosure of AI system architecture through job postings is a risk that most organisations have not identified, documented, or included in their AI risk register.

This matters not because ISO 42001 certification requires specific job description policies — it doesn't — but because the clause 6.1 process, done rigorously, should surface "what information about our AI systems is publicly available, and to whom?" The job posting channel is a systematic disclosure mechanism that most organisations haven't included in that analysis. Running the PromptShield job post scanner quarterly produces the artefact that clause 6.1 requires: a documented inventory of what has been disclosed and what the risk implications are. Legal review of specific compliance obligations remains with qualified counsel.

MITRE mapping

The job posting reconnaissance step maps directly to established ATT&CK techniques. The downstream ATLAS techniques describe attack methods that become more targeted once job posting signals are incorporated — they apply only where follow-up investigation confirms a live, accessible system and the relevant conditions.

• T1591.002 — Gather Victim Org Information: Business Relationships: job postings disclose vendor relationships with model providers, observability platforms, and AI tooling vendors — this mapping applies directly from reading publicly available job descriptions
• T1593.001 — Search Open Websites/Domains: Social Media: LinkedIn and public ATS platforms (Greenhouse, Lever) are the primary sources for job posting reconnaissance — applies directly from public job listing access
• T1589.003 — Gather Victim Identity Information: Employee Data: role titles, seniority levels, and tool requirements in job postings indicate which personnel have AI system access — applies from job description content combined with LinkedIn profile review
• AML.T0054 — LLM Prompt Injection: knowledge of the target's orchestration framework (from job posting signals) enables more targeted payload construction; the technique itself requires an accessible target system — this mapping describes the attack that job posting reconnaissance enables, not the reconnaissance step itself
• AML.T0057 — LLM Data Leakage: job posting language indicating data access scope (e.g. 'RAG over transaction data') narrows what data an injection payload would target; requires a successful injection pathway and confirmed data access to exploit — the posting signals the potential scope, not the confirmed attack surface

What to do — three tiers

The good news is that the remediation here doesn't require a new tool, a new budget, or a new security control. It requires a process change in a team — recruiting — that has never thought of job descriptions as security artefacts. That conversation is easier than it sounds, because the fix is simple and the ask is concrete.

Immediate: Audit all currently live job postings for named AI tools, model providers, framework names, and data source descriptions. Replace specifics with category-level language. "Experience with LLM frameworks" is sufficient for recruiting purposes; "LangChain over our transaction database" is not. "Familiarity with AI observability tools" is sufficient; "LangSmith and Arize" is not. Pull every job description that contains an AI-specific tool name and rewrite the technical requirements section before the week is out.

Short-term: Add AI stack disclosure to the checklist that job descriptions go through before posting. Security teams already review some job descriptions for credential or security tool disclosure — extend that review to AI tools. Brief the recruiting and HR teams on the threat model: they are not at fault for writing what the hiring manager asked for, but they need to understand why the review step matters. The goal is not to prevent accurate job descriptions — it's to prevent descriptions that are more detailed about the AI attack surface than the company's own threat model.

Long-term: Build a tiered AI disclosure policy analogous to how mature organisations handle security tool disclosure. Tier 1 (public): general AI capability references, category-level tool descriptions, cloud provider regions. Tier 2 (internal): specific model providers, framework names, infrastructure topology. Tier 3 (confidential): data access scope, guardrail implementation details, system prompt structure. Job descriptions live at Tier 1. Architectural documentation lives at Tier 2 or 3. Align this classification with ISO 42001 clause 6.1's risk identification requirements — what's publicly known about the AI system is part of the risk context.