Loading...
Learn how to nail the STAR-format behavioral question about handling an LLM agent gone wrong in production — what Infosys interviewers really want to hear.
When an Infosys interviewer asks, "How would you handle a situation where an LLM agent takes an unintended destructive action in production?", they're not just asking about incident response. They're checking three things at once:
Here's the thing most candidates miss: the best answer is not a panicked war story. It's a composed, structured narrative that shows you've thought deeply about AI safety, observability, and responsible deployment. Let's walk through exactly how to build that answer.
For a behavioral question at this level, the interviewer is looking for a STAR-format response — Situation, Task, Action, Result. But for an AI/ML engineering role at Infosys, they layer on extra expectations:
| Signal | Weak Answer | Strong Answer | |---|---|---|| | Technical depth | "I restarted the service" | "I triggered a circuit breaker and rolled back the agent's tool permissions" | | Ownership | "The team handled it" | "I was the on-call engineer and I owned the incident to resolution" | | Prevention mindset | "We were more careful next time" | "I introduced a sandboxed dry-run mode and human-in-the-loop approval gates" | | AI-specific knowledge | Generic incident response | Understands LLM non-determinism, prompt injection, tool-call risks |
The interviewer loses confidence fast when you talk about LLM incidents like they're just regular software bugs. They're not. An LLM agent can be instructed through adversarial input, hallucinate tool arguments, or chain actions in ways no single line of code predicted.
Let me give you a scenario you can adapt and make your own. Imagine you're on a team that deployed an LLM-powered customer support agent. The agent had access to tools: read order details, issue refunds, and escalate tickets.
Due to a poorly scoped system prompt, when a user typed a specific phrase pattern, the agent interpreted it as an internal admin command and began issuing bulk refunds — $0 for hundreds of orders — effectively corrupting the billing system.
Here's how you build the STAR narrative:
"We had deployed an LLM agent integrated with our e-commerce backend. It had tool-calling capabilities to query orders and process refunds. Within 48 hours of production launch, our monitoring dashboard flagged an anomalous spike in refund transactions — all for $0 amounts — affecting roughly 300 orders over 90 minutes."
"As the AI platform engineer on call, my immediate task was to contain the blast radius, identify root cause, and restore data integrity — all while communicating status to the business and product teams."
This is where you shine. Walk through three phases:
Phase 1 — Immediate Containment:
Your first job is to stop the bleeding. Here's roughly what that looks like in code — a feature flag or circuit breaker to disable the agent's tool access:
# Emergency kill switch — disable destructive tool permissions
import redis
def disable_agent_tool(agent_id: str, tool_name: str):
"""
Immediately revoke a specific tool permission for an LLM agent.
This is called during incident triage to contain blast radius.
"""
r = redis.Redis(host='localhost', port=6379)
key = f"agent:{agent_id}:tools:{tool_name}:enabled"
r.set(key, "false", ex=3600) # disable for 1 hour, then auto-review
print(f"[INCIDENT] Tool '{
You'd say something like: "I immediately toggled the agent offline via a feature flag and revoked its write-access tool permissions through our permission store. This stopped further $0 refunds within minutes."
Phase 2 — Root Cause Analysis:
You pull logs. In a well-designed system, every tool call made by the agent is logged with the full prompt context, tool name, and arguments.
# Structured logging for every LLM tool call — this is what saves you in incidents
import json
import logging
from datetime import datetime
logger = logging.getLogger("llm_agent_audit")
def log_tool_call(session_id: str, tool_name: str, arguments: dict, result: dict):
"""
Audit log for every tool invocation by the LLM agent.
Critical for post-incident forensics and compliance.
"""
audit_record = {
"timestamp": datetime.utcnow().isoformat(),
"session_id": session_id,
"tool_name": tool_name,
"arguments"
In the RCA, you'd find the agent was interpreting the phrase "just give me a zero" — a casual customer expression — as an instruction to issue a zero-dollar refund. The system prompt lacked explicit disambiguation rules for dollar amounts.
Phase 3 — Remediation and Prevention:
After restoring the 300 affected orders (working with the database team to reverse the transactions), you implement:
"We restored all 300 affected orders within 4 hours with zero customer-facing financial loss — the transactions were reversed before billing cycles closed. We shipped the human-approval gate within the next sprint, reduced agent-related incidents by 80% over the following quarter, and this incident became the foundation of our internal LLM agent safety runbook."
Here are the real traps I've seen candidates fall into:
Here's a template for how to open and navigate this answer confidently:
"Great question — this is actually something I've thought a lot about, and I had a direct experience with this. Let me walk you through it using the STAR format."
Then after delivering the core story:
"The key lesson for me was that LLM agents need layered defenses — not just at the model level, but at the tool permission level, the input validation level, and the monitoring level. No single guardrail is sufficient."
If you don't have direct experience, be upfront but demonstrate knowledge:
"I haven't personally experienced this exact scenario in production, but I've designed systems to prevent it and studied real-world cases. Let me walk you through how I would handle it and the safeguards I'd have in place..."
This is honest and shows architectural thinking — which interviewers respect far more than a vague war story.
Expect the interviewer to push deeper. Here's what they'll likely ask and how to respond:
"How would you have prevented this in the first place?" Talk about pre-production red-teaming, strict tool permission scoping (principle of least privilege), dry-run environments, and output validators that check tool arguments against a safe schema before execution.
"How do you monitor an LLM agent in production?" Mention structured audit logging of every tool call (show the code pattern above), anomaly detection on tool call frequency and argument distributions, and alerting when output patterns deviate significantly from baseline.
"How would you explain this to a non-technical stakeholder?" This is a communication test. Say something like: "I'd explain that our AI assistant misunderstood a common phrase and applied it literally in a way we hadn't anticipated. We've since added a confirmation step for any financial actions, similar to how banking apps ask you to confirm before a large transfer."
"What's the difference between this and a regular software bug?" Nail this one. "A regular bug has a deterministic cause — a specific code path fails. LLM failures are probabilistic and context-dependent. The same input can produce different outputs on different runs, and the agent can be influenced by adversarial or unexpected user inputs in ways that static code cannot. That means testing strategies, monitoring, and guardrails all need to account for non-determinism."
Here's what to remember when you walk into that Infosys interview:
You've got this. Practice the story out loud at least three times before the interview — the STAR format should flow naturally, not feel like you're reading from a script.