← American Express Interview Insights

American Express·AI Engineer·Technical Phone Screen·Senior

Senior
Jun 2026

Summary

Amex AI Engineer interview that went deep on LLM security, specifically prompt injection. The whole session felt like one long threat modeling exercise and I was not fully prepared for how far into the weeds they wanted to go on mitigations.

Questions Asked (5)

Q1

What is the difference between direct prompt injection and indirect prompt injection, and why does the distinction matter for threat modeling?

System DesignTechnical Trade-offs
Author's notes

I explained direct as a user crafting malicious input themselves vs indirect as the attack arriving through retrieved content or tool output.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clearly defining direct and indirect prompt injection, emphasizing the source of the malicious input (user vs. external data). Then explain how the distinction affects threat modeling, focusing on trust boundaries, attack surface, and mitigation strategies. Use a concrete example from a financial services context to illustrate the risks.

Pro tip: Highlight that indirect prompt injection is often more dangerous in production systems because it can bypass user-facing input filters and exploit trusted data sources, making it a critical consideration for AI systems that ingest external content.

1. Define direct prompt injection

Explain that direct prompt injection occurs when a user intentionally provides malicious input directly to the model, attempting to override instructions or extract sensitive information.

2. Define indirect prompt injection

Describe indirect prompt injection as when malicious content is embedded in external data sources (e.g., documents, emails, web pages) that the model processes, leading to unintended actions.

3. Contrast attack vectors and trust boundaries

Compare how direct injection exploits the user-model interface, while indirect injection exploits the model's trust in external data, crossing different trust boundaries.

4. Explain threat modeling implications

Discuss why the distinction matters: direct injection is often mitigated by input sanitization and user authentication, whereas indirect injection requires securing data pipelines, validating external content, and limiting model permissions.

5. Provide a relevant example

Give a concrete example, such as an AI assistant summarizing customer emails that contain hidden instructions to exfiltrate data, to illustrate the real-world impact in a financial institution.

Key Points to Mention

  • Trust boundaries: direct injection crosses user-to-model boundary; indirect crosses data-to-model boundary.
  • Attack surface: indirect injection expands the attack surface to any external data the model consumes.
  • Mitigation strategies: input validation, output encoding, sandboxing, least privilege for model actions.
  • Threat modeling: indirect injection requires securing the entire data supply chain, not just user inputs.
  • Real-world impact: potential data leakage, unauthorized actions, and compliance violations in finance.
  • Defense in depth: combining technical controls with monitoring and anomaly detection.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Walk through the main threat categories in LLM agent systems, covering data exfiltration, privilege escalation, jailbreaks, and tool misuse.

System DesignTechnical Trade-offs
Author's notes

Covered all four but my answer on privilege escalation was thin.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Structure your answer around the four threat categories, explaining each with a concrete example and its impact on an LLM agent system. Then discuss how these threats interrelate and propose layered mitigations, emphasizing defense-in-depth and secure design principles relevant to a financial institution like American Express.

Pro tip: Tie each threat to a real-world consequence in financial services—such as unauthorized transactions or data breaches—and mention how you would validate mitigations through red-teaming and continuous monitoring, showing you think beyond just model-level fixes.

1. Define the LLM agent attack surface

Briefly outline the components of an LLM agent system (model, tools, memory, external APIs) and how each expands the attack surface. This sets the stage for categorizing threats.

2. Explain data exfiltration

Describe how an agent might leak sensitive data through prompts, tool outputs, or side channels, and give an example like extracting customer PII via crafted queries. Mention mitigation such as output filtering and data access controls.

3. Explain privilege escalation

Discuss how an attacker could trick the agent into performing actions beyond its intended permissions, such as accessing admin tools or escalating via tool chaining. Highlight the need for least-privilege design and runtime authorization checks.

4. Explain jailbreaks and tool misuse

Cover jailbreaks as bypassing safety guardrails via adversarial prompts, and tool misuse as abusing legitimate tools for malicious ends (e.g., sending unauthorized emails). Emphasize input sanitization, tool allowlisting, and behavioral monitoring.

5. Propose layered mitigations and trade-offs

Summarize a defense-in-depth strategy combining model alignment, input/output validation, sandboxing, and human oversight. Discuss trade-offs between security, usability, and latency, showing balanced engineering judgment.

Key Points to Mention

  • Prompt injection as a root cause for jailbreaks and data exfiltration
  • Least privilege and sandboxing for tool access to prevent privilege escalation
  • Output sanitization and data loss prevention (DLP) to block exfiltration
  • Tool allowlisting and input validation to prevent tool misuse
  • Red-teaming and continuous monitoring for emerging threats
  • Compliance and regulatory considerations in financial services (e.g., PCI DSS, GDPR)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

What mitigation strategies would you apply to defend an LLM agent against prompt injection, and what are the limits of each?

System DesignTechnical Trade-offs
Author's notes

This is where the conversation got long.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Structure your answer by first categorizing prompt injection defenses into layers (input, model, output, and system-level), then for each layer describe the mitigation and its limitations. Emphasize a defense-in-depth strategy, acknowledging that no single solution is foolproof, especially in high-stakes domains like finance.

Pro tip: Highlight that prompt injection is an evolving threat and that continuous monitoring and red-teaming are essential; also mention that some mitigations may trade off with model performance or user experience, so balancing is key.

1. Input Sanitization and Filtering

Describe techniques like input validation, escaping, and using allowlists to block malicious patterns. Mention limitations such as evasion via obfuscation or novel attack vectors.

2. Model-Level Defenses

Discuss prompt engineering (e.g., clear instructions, delimiters), fine-tuning for robustness, and using smaller specialized models to detect injections. Note limitations like model susceptibility to adversarial examples and the difficulty of covering all attack surfaces.

3. Output Sanitization and Monitoring

Explain post-processing checks, anomaly detection, and human-in-the-loop for sensitive actions. Limitations include false positives, latency, and the challenge of defining normal behavior.

4. System-Level Controls

Cover architectural safeguards like sandboxing, least privilege, and separating trusted and untrusted components. Limitations include complexity, cost, and potential single points of failure.

5. Continuous Improvement and Red Teaming

Emphasize ongoing testing, updating defenses, and learning from incidents. Limitation: resource-intensive and reactive to new threats.

Key Points to Mention

  • Defense-in-depth: no single mitigation is sufficient; combine multiple layers.
  • Prompt injection can be direct or indirect (e.g., via retrieved documents), so consider both.
  • Trade-offs between security, performance, and usability (e.g., strict filters may block legitimate queries).
  • Importance of context: in finance, compliance and data privacy amplify the need for robust defenses.
  • Use of AI-specific tools like prompt injection detectors or adversarial training.
  • Limits: attackers adapt, so defenses must evolve; also, some mitigations may not scale well.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

How would you design an end-to-end defense for an LLM agent system deployed in a financial services context, assuming defense-in-depth?

System DesignTechnical Trade-offs
Author's notes

Probably my best answer of the session.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by framing the problem around the unique risks of LLM agents in finance: data leakage, prompt injection, and regulatory compliance. Then walk through a layered defense-in-depth architecture covering input, model, output, and runtime, emphasizing trade-offs between security, latency, and user experience. Conclude with monitoring and governance to ensure continuous protection.

Pro tip: Tie every layer to a specific financial regulation (e.g., GLBA, SOX, PCI DSS) and show how you'd measure its effectiveness with metrics like false positive rate and containment time—this demonstrates you understand both security and business impact.

1. Threat Modeling & Risk Assessment

Identify assets (PII, transaction data), threat actors (external attackers, malicious insiders), and attack vectors (prompt injection, data poisoning, model inversion). Prioritize risks based on regulatory and financial impact.

2. Input & Preprocessing Defenses

Implement input validation, sanitization, and prompt hardening to block injection attacks. Use allowlists for user intents and detect anomalous patterns with ML-based filters.

3. Model & Runtime Protections

Secure the model with access controls, encryption, and differential privacy. Deploy runtime guards like rate limiting, sandboxing, and real-time anomaly detection to contain breaches.

4. Output & Post-processing Controls

Filter outputs for sensitive data leakage, enforce compliance policies, and apply human-in-the-loop for high-risk actions. Use output watermarking and audit logs for traceability.

5. Monitoring, Governance & Continuous Improvement

Set up centralized logging, alerting, and regular red-teaming. Establish governance with clear incident response and update defenses based on emerging threats and audit findings.

Key Points to Mention

  • Defense-in-depth layers: input validation, model hardening, output filtering, runtime monitoring
  • Regulatory compliance: GLBA, SOX, PCI DSS, GDPR, and financial industry best practices
  • Trade-offs: balancing security with latency, cost, and user experience
  • Specific LLM threats: prompt injection, data leakage, model inversion, adversarial inputs
  • Monitoring and incident response: metrics like false positive rate, containment time, and audit trails
  • Human-in-the-loop and explainability for high-stakes financial decisions

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q5

How does content provenance help defend against indirect prompt injection, and where does it fall short?

System DesignTechnical Trade-offs
Author's notes

Blanked for a second on 'provenance' as a formal term even though I knew the concept.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining indirect prompt injection and content provenance, then explain how provenance acts as a trust signal to filter or sanitize untrusted content before it reaches the model. Next, discuss the limitations of provenance, such as spoofing, incomplete coverage, and the challenge of maintaining provenance across transformations, and conclude with complementary defenses like input validation and output monitoring.

Pro tip: Emphasize that provenance is a necessary but not sufficient defense; it shifts the problem to trust management and requires a defense-in-depth strategy. Mention that in high-stakes domains like finance, you must also consider adversarial attacks on the provenance system itself.

1. Define the threat and the defense

Briefly explain indirect prompt injection: malicious instructions embedded in external content that the model processes. Then define content provenance as metadata about the origin and integrity of content, which can be used to assess trustworthiness.

2. Explain how provenance helps

Describe how provenance enables systems to distinguish trusted sources (e.g., internal documents) from untrusted ones (e.g., user-generated content). This allows for policies like ignoring or sanitizing untrusted content before it reaches the model.

3. Identify where provenance falls short

Discuss limitations: provenance can be spoofed if not cryptographically secured; it may not cover all content (e.g., dynamically generated text); and it can be lost during transformations like summarization or translation.

4. Propose complementary defenses

Suggest additional measures such as input sanitization, output monitoring, and model-level defenses (e.g., instruction hierarchy) to create a defense-in-depth approach.

5. Conclude with a balanced assessment

Summarize that provenance is valuable but not a silver bullet, and that a layered security strategy is essential for robust protection.

Key Points to Mention

  • Indirect prompt injection: attacker embeds malicious instructions in external content that the LLM processes.
  • Content provenance: metadata about origin, integrity, and chain of custody (e.g., C2PA, digital signatures).
  • Provenance enables trust-based filtering: only allow content from trusted sources to be processed as instructions.
  • Limitations: provenance can be spoofed, incomplete, or lost during transformations (e.g., summarization).
  • Complementary defenses: input validation, output monitoring, instruction hierarchy, and sandboxing.
  • Defense-in-depth: no single defense is sufficient; combine provenance with other techniques.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.