AI Agent & MCP Security Interview Questions

Inventory the data, untrusted inputs and outbound routes, including tools with two roles. Propose one enforced restriction and explain what the first pass leaves unresolved.

Start with the useful task, its data paths and its effective authority. Produce explicit backend invariants, bounded execution and a testable release decision that covers ordinary work as well as denied effects.

Compare each task’s required effects with the functionality, permissions and autonomy the system exposes. Narrow the effective authority at enforceable boundaries while preserving legitimate workflows.

Review an integration by tracing model input, process access and credential recipients. Then name the component that refuses each unauthorized action.

Build a permission worksheet for each tool: acting principal, task grant, objects, recipients, bounds and enforcement. Treat reads and reversible writes as potentially consequential.

Distinguish metadata review from runtime authorization. Work through an uncalled tool, a changed definition and a server whose behavior changes without new metadata.

Design the review around a permitted action and an understandable consequence. Evaluate whether people catch relevant changes, while keeping authorization, exact-action binding and alternate delivery paths enforced outside the model.

Define automatic work within an existing grant, decisions that need new authority and prohibited effects. Assess data disclosure, impact, recovery and uncertain inputs without turning every step into another confirmation.

Follow the write, retrieval and execution paths separately. A remembered claim can persist without becoming policy; prove which records later tasks receive and which actions the resource service permits.

Contain affected authority, preserve evidence in parallel and reconcile actual effects. Work through shared inputs, queued jobs, uncertain outcomes and a tested path back to useful service.

Treat repository code and shell execution as part of the threat model. Define reachable files, credentials, services and publication paths, then verify the actual sandbox and CI handoff rather than trusting command names.

Trace which private data can reach which destinations when browsing and email share a task. Rank harms by the capabilities and checks actually present, and preserve useful combined workflows within a narrow grant.

Connect task authority, evidence, dispatch attempts and observed effects. Learn what references, hashes and signed logs can establish, and test collection gaps without overcollecting sensitive data.

Separate model judgment from enforceable invariants, then inspect the inputs and state transitions used by the policy code. Deterministic code is useful only when its authority and facts are trustworthy.

Bound work where it is dispatched, account for concurrent branches and retries, and keep uncertain operations reserved. Choose limits from workload evidence and operational capacity, then preserve useful progress when a bound is reached.

Separate task authorization, path resolution and safe publication. A resolved path is only a snapshot; test concurrent changes, protected targets and aggregate limits without treating a few passing cases as proof.

Contain financial actions and reconcile provider state in parallel. Work through a synthetic exposure table, uncertain dispatch, cancellation limits and the evidence needed for a controlled restart.

Trace field origin through telemetry, summaries and response proposals. Preserve evidence, verify current targets and playbooks, and test both missed threats and harmful containment.

Define current task authority and forbidden effects, test policy and agent behavior together, and report proposals, outcomes and useful completion with honest denominators and uncertainty.

Map the caller, task grant, data audience and execution boundary at each handoff. Explain how a valid internal message can still request an unauthorized action.

Choose narrow extraction or full-text reading according to the task. Preserve source evidence and uncertainty, and enforce data audiences and action authority independently of extracted claims.

Distinguish profile, device and account boundaries, then bind UI actions to the intended app, recipient and effect. Screenshots and accessibility trees provide observations, not trusted authorization.

Separate false-information spread, borrowed authority and runaway work. Put shared limits and stop checks at the propagation paths, then recover without repeating completed effects.

Review customer, operator and service authority separately. Enforce order access and email release policy, govern contact changes, and test valid work alongside unauthorized reads and disclosures.

Map effective authority, test component and handoff boundaries in authorized isolation, and report captured effects with coverage limits. Keep adaptive discovery separate from estimates of production risk.

Design investigation, response policy and execution with distinct authority. Build an action matrix, handle failed dependencies and tenant boundaries, and evaluate useful work alongside missed incidents and wrongful containment.

Design a refund ledger that handles authorization, concurrent reservations, distinct partial refunds and uncertain provider outcomes. A stable retry key helps, but does not enforce the business budget.

Freeze the resolved purchase, authenticate the approver and verify the same action at execution. Then handle mutable addresses, simultaneous workers and a supplier timeout without treating a hash as a complete transaction protocol.

Separate proposal, verification and deployment authority. Bind approval to the executed artifact and environment, protect every policy dependency, and plan for drift, partial application and limited rollback.

Choose fixed query tools or bounded exploratory SQL, then verify the database role, tenant context, views, callable functions and resource controls. Read-only and row limits alone do not protect confidentiality or cost.

Compare each proposed action with the task’s existing grant, current policy and remaining budget. Continue within that scope; stop when authority expires or the action changes materially, and preserve the state of work already dispatched.

Separate enforceable permissions from behavioral review. Measure the checker on the proposer’s actual failures, track legitimate actions it blocks, and test the execution service even when every model recommends proceeding.

Define the compromise scope and secret boundary, map direct and indirect capability paths, and assemble evidence with explicit assumptions. Denial tests and model refusals are useful observations, not universal proofs.

Treat a wider memory audience as a publication decision. Check the publisher, evidence, disclosure scope and version separately; repeated copies, familiar account names and a verified label do not establish all four.

Define memory classes and their purpose, then inventory active records, derivatives, in-flight tasks and restored copies. Report retrieval denial and physical removal as separate milestones with evidence for each.

Define the partner identity, permitted operations, disclosure rules and commitment states. Verify claims against authorized evidence and reconcile disputed or uncertain effects.

Separate reachable authority, forbidden proposals, gate decisions and confirmed effects. Compare designs with matched tasks, explicit denominators and uncertainty; tool counts and zero observed failures are not universal risk scores.

Compare actions with current grants and policy, distinguish unusual behavior from violations, and handle legitimate task revisions. Verify observation coverage and respond to the affected operation.

Map influence through memory, retrieval, tool metadata, outputs and shared artifacts. Separate persistence from actual impact, govern publication, and recover with explicit coverage of derivatives and ongoing work.

Repository instructions can influence a model; configuration can change execution. Trace creation, replacement and startup before deciding where approval must hold.

Browser origin isolation still applies to web content. Explain the separate authority of an agent that reads and acts across sites, then constrain data flow, destinations and consequential actions at the agent boundary.

One agent is a design review. Four hundred agents is an operations problem: who owns each, what it can touch, how much it can spend, and how you stop one, a class or all of them in minutes.

A gateway is the one place every tool call passes, which makes it the natural home for policy. It is also blind to everything that does not pass through it, and that is the half of the answer most candidates skip.

Design-time controls decide what an agent may do. Runtime protection watches what it actually does, at four different layers, and each layer catches something the others miss.

A2A standardises how agents find and talk to each other. It does not decide who to trust, what to share or what to believe, and those three decisions are the answer.

Giving an agent a card number is the wrong design. The scored answer separates consent, spending limits and agent identity, and shows how 2025-26 protocols handle each.

A skill is instructions plus code that runs with the agent's own permissions, with no process boundary in between. The scored answer reviews it like software and like a prompt, because it is both.