Security and Reliability Interview Questions for AI Apps

1. Establish identity once, from a verified token, never from the body or the model.
2. List every store and copy: index, cache, idempotency store, prompt, log, trace, error message.
3. Scope each by tenant and user at the lowest layer, so one careless handler cannot skip it.
4. Do not rely on the prompt to hide data.
5. Test with two identities and identical input.

Strong answer example. I would answer with a table of paths, then say which are built.

Verified: capstone/fde-product-discovery-copilot/app/idempotency.py

    def get(self, identity: Identity, key: str, body: str) -> dict[str, object] | None:
        """Keys are scoped to tenant and user, so one caller can never read another's response."""
        with self._lock:
            entry = self._items.get((identity.tenant, identity.user_id, key))
        if entry is None:
            return None
        if entry[0] != self._fingerprint(body):
            raise IdempotencyConflict("This Idempotency-Key was already used with a different request.")
        return entry[1]

Verified: capstone/fde-product-discovery-copilot/tests/test_api.py

def test_keys_are_scoped_to_the_caller(client: TestClient) -> None:
    a = client.post(URL, json={"request": PUMPS}, headers={**bearer(PUBLIC), "Idempotency-Key": "shared"}).json()
    other = Identity("someone-else", "other-tenant", "public")
    b = client.post(URL, json={"request": PUMPS}, headers={**bearer(other), "Idempotency-Key": "shared"}).json()
    assert a["trace_id"] != b["trace_id"]

The test sends the same key from two tenants and gets two separate runs. OWASP's LLM02:2025 guidance includes least-privilege access and secure configuration so error messages do not leak details, and it warns that restrictions placed only in a system prompt may not be honoured.

I would add a tenant id on every chunk, checked in the same predicate as visibility, plus a three-tenant test. One shared index with a filter is cheaper but one filter bug exposes everyone; separate indexes isolate better and cost more to run. My default is a shared index with a test that fails the build, moving to separate indexes for tenants with contractual isolation.

Common mistakes.

• Scoping a cache by the client's key alone.
• Logging full prompts "for debugging" and forgetting them.
• Filtering results after retrieval.

Follow-up questions.

• How would you prove that a tenant's data was deleted from the index, the cache and the logs?
• What goes in a trace store, and who can read it?
• A support engineer needs to debug a customer's bad answer. What can they see?

Scoring rubric.

Q3. The model provider fails one call in twenty and sometimes hangs. Design the retries, the idempotency and what the user sees.

What it assesses. Whether you know that retries can multiply load and delay, that a POST needs a safe way to be repeated, and that degraded answers must say they are degraded. Every retry is another paid inference, and OWASP LLM10:2025 Unbounded Consumption (LLM06:2026) lists rate limits, timeouts and throttling among its preventions.

Answer framework.

1. Retry only what can succeed on a second try: timeouts, rate limits, server errors. Never validation or authorisation errors.
2. One layer owns retries; all others fail fast.
3. Budget time: a total deadline, a timeout per attempt, backoff with jitter.
4. Make repeats safe with an idempotency key and a conflict rule.
5. Degrade honestly: return what you have with the reason, or refuse.

Strong answer example. Arithmetic first.

If each attempt fails 5% of the time and failures are independent, all three of three attempts fail 0.05 x 0.05 x 0.05 = 0.000125, or 0.0125%. But time adds up: a 10 second timeout with three attempts and waits of 1 and 2 seconds is 10 + 1 + 10 + 2 + 10 = 33 seconds in the worst case. And layers multiply: three attempts at each of three layers can turn one request into 3 x 3 x 3 = 27 calls. So one layer owns retries.

Illustrative numbers: the failure rate, timeout and waits are invented for this example.

The reference code adds no network retries of its own. Its one retry is a repair: if the model's JSON is invalid, ask once more with the error, then fail with a 502. The Anthropic SDK that its optional adapter wraps does retry by default (2 retries on connection errors, 408, 409, 429 and 5xx, as of 2026-11-02), so a real deployment already has a second retry layer to account for.

Verified: capstone/fde-product-discovery-copilot/tests/test_llm.py

def test_second_failure_raises_and_never_loops() -> None:
    p = ScriptedProvider(["nope", "still nope", GOOD])
    with pytest.raises(StructuredOutputError):
        complete_structured(p, extract_messages("x"), Requirements)
    assert len(p.calls) == 2 and p.texts == [GOOD]  # the third answer was never requested

For repeated POSTs, RFC 9110 says a client should not automatically retry a non-idempotent request unless it knows the request is idempotent or can detect that the first one was not applied. The service accepts an Idempotency-Key header, a convention the service implements itself. The same key and body replays the stored response, the same key with a different body returns 409, and keys are scoped to tenant and user.

The gap: lookup, run and store are separate steps. In the test below, two overlapping requests with the same key both ran the whole pipeline. A production store must reserve the key before running, then make the second request wait or return a conflict.

Verified: capstone/fde-product-discovery-copilot/lessons/REF-security-reliability/test_ref_security_reliability_checks.py

def test_two_requests_with_the_same_idempotency_key_both_run_when_they_overlap() -> None:
    svc = Services(SETTINGS, SERVICES.catalog, SERVICES.store, MeetingPointProvider())
    app = create_app(SETTINGS, svc)
    headers = {**bearer(PUBLIC), "Idempotency-Key": "same-key"}
    results: list[Any] = []

    def send() -> None:
        with TestClient(app) as client:
            results.append(client.post("/api/v1/discovery", json={"request": PUMPS}, headers=headers))

    threads = [threading.Thread(target=send) for _ in range(2)]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    assert [r.status_code for r in results] == [200, 200]
    assert results[0].json()["trace_id"] != results[1].json()["trace_id"]  # two real runs, not one run and a replay
    assert all("Idempotent-Replay" not in r.headers for r in results)

On degradation: when the workflow hits its step or time limit, the pipeline continues with what it has, adds an open question saying the search stopped early, and caps confidence below high. When the documents cannot support a question it refuses with a fixed message. A provider outage is still a generic 500 (see the Python and API page).

Verified: capstone/fde-product-discovery-copilot/tests/test_discovery.py

def test_workflow_that_never_finishes_is_cut_off_and_reported(services: Services) -> None:
    looping = json_text({"action": "tool", "tool": "search_catalog", "args": {"query": "pump"}})
    svc = Services(Settings(max_steps=3), services.catalog, services.store, OverrideProvider(plan_next_step=looping))
    r = run_discovery(PUMPS, PUBLIC, svc).response
    assert any("stopped early" in q for q in r.open_questions) and r.confidence != "high"

Common mistakes.

• Retrying every error, including 400 and 403.
• Backoff without jitter, so every client retries at the same moment.
• An idempotency key with no scope, or with no check that the body matches.
• Returning a confident guess when the pipeline stopped early.

Follow-up questions.

• A duplicate arrives while the first request is still running. What status do you return?
• Where should the idempotency store live in production, and how long should keys live?
• When would you add a circuit breaker?

Scoring rubric.

Q4. An auditor asks who asked what, what the system answered and why. What do you log, what do you leave out, and can you reconstruct an answer?

What it assesses. Whether you treat logs as both evidence and a risk. The interviewer wants a rule for what goes in, a trace id that ties a response to a record, and an honest statement of what cannot be reconstructed.

Answer framework.

1. Decide the questions the log must answer: who, when, what action, what outcome, which version.
2. Log facts and ids, not text or secrets, and enforce that in code.
3. Tie the response and the log with one trace id.
4. Record privileged decisions: who approved what, bound to which arguments.
5. Decide retention, access and tamper protection.
6. State what you cannot reconstruct and what storing it would cost.

Strong answer example. The reference service writes one structured line per request.

Verified: capstone/fde-product-discovery-copilot/app/main.py

        log_event(
            "discovery", trace_id=result.trace_id, user_id=identity.user_id, tenant=identity.tenant, role=identity.role,
            request_chars=len(body.request), refused=result.refused, confidence=result.confidence,
            recommendations=len(result.recommendations), workflow_status=run.workflow_status,
            workflow_steps=result.usage.workflow_steps, input_tokens=result.usage.input_tokens,
            output_tokens=result.usage.output_tokens, cost_eur=result.usage.estimated_cost_eur,
        )

It records the user, tenant and role, the request's length (not its text), whether it refused, the confidence, the number of recommendations, the workflow status and steps, token counts and cost. Field names such as request, token, authorization, api_key and email are dropped by code, and a test checks that a distinctive word from the request and the bearer token do not reach the log.

Verified: capstone/fde-product-discovery-copilot/tests/test_api.py

    fields = records[0].fields  # type: ignore[attr-defined]
    assert fields["role"] == "public" and fields["request_chars"] == len(PUMPS) and "trace_id" in fields
    dumped = json.dumps(fields)
    assert "wireless" not in dumped and headers["Authorization"].split()[1] not in dumped

The same trace id is in every error body and in the X-Trace-Id response header, so a support ticket maps to one log line. One gap: an unexpected 500 carries the id in its body but not in the header (the unhandled-exception handler runs outside the middleware that adds it). Approvals carry the requester and a digest of the exact arguments.

Verified: capstone/fde-product-discovery-copilot/app/workflow/approval.py

class ApprovalRequest:
    approval_id: str
    digest: str
    requested_by: str
    status: Literal["pending", "approved", "used"] = "pending"

Can I reconstruct an answer? Not fully, and that is a choice. The line holds no request text, no retrieved chunk ids and no model output, so I can show who asked and what the pipeline did, not the exact evidence. Storing chunk ids, which the pipeline already computes, would let me rebuild evidence from a versioned document store. Storing prompts gives a full replay but creates a store of customer text that needs retention, access control and redaction. I would propose ids first, and prompts only for a consented sample.

Gaps in the reference build: logs go to standard output with no retention or tamper protection, approvals live in memory, and denied requests (401 and 403) are not logged by the service.

Common mistakes.

• Logging whole prompts "temporarily".
• No trace id, so a complaint cannot be tied to a record.
• Logs that the application can edit.

Follow-up questions.

• A user asks you to delete their data. What happens to the user id in your logs?
• Who can read the logs, and how is that access itself recorded?
• What would you alert on first?

Scoring rubric.

For the threat model behind Q1 and Q2, read security and threat modelling.

Last verified: 2026-11-02

How to practise

• Run ./.venv/Scripts/python -m pytest lessons/REF-security-reliability -q in the capstone folder and read each test name as a claim you could defend.
• Redo the Q3 arithmetic with your own failure rate, timeout and number of layers.
• Write the three-tenant test that Q2 proposes and see which part of the reference build fails it.
• Explain the gap in the idempotency store to a friend in three sentences.
• Score yourself with each rubric and repeat the criterion you scored lowest.

Next

Continue to Interview questions: behavioral, which covers ownership, conflict, failure and influence with a structure for each story.