Foot-in-the-Door: How Conversational Momentum Tricks AI Agents

A Foot-in-the-Door (FITD) attack gets an AI agent to accept a series of small, harmless requests before asking for a sensitive action. Each accepted step makes the next step look like a normal continuation of the same job. When the final request crosses a permission boundary, the agent may follow it because the surrounding sequence feels authorized.

The attack matters whenever an agent can read untrusted content and call tools. A calendar entry, document, ticket, or web page can carry the bait. FITD is described in Breaking ReAct Agents: Foot-in-the-Door Attack Will Get You In.

Why does a chain of harmless actions matter?

Many agents use ReAct, short for Reasoning and Acting. The agent alternates between choosing a tool, reading its result, and deciding what to do next. The whole sequence remains in the agent’s working context, so earlier successful actions influence later decisions.

A direct request to send private data is easy to recognize as risky. FITD changes the path to that request. An attacker first supplies a sequence such as <harmless organization request 1>, <harmless lookup request 2>, and <harmless summary request 3>. The agent performs each one, and the sequence builds behavioral momentum: the next action appears to belong to the same approved workflow.

The final request can then be <unauthorized external transfer request>. The agent may treat it as the fourth step in a familiar process instead of asking whether the user ever authorized external sharing. The core mistake is confusing continuity with permission. A tool result can provide information for a task, but it must not grant new authority to call a more sensitive tool.

sequenceDiagram
participant U as User
participant A as ReAct Agent
participant D as Calendar or notes data
participant T as Tool set
U->>A: Summarize the afternoon schedule
A->>T: <read calendar>
T-->>A: Events plus untrusted note
A->>T: <organize attendees>
T-->>A: Harmless list result
A->>T: <look up meeting notes>
T-->>A: Harmless notes result
A->>T: <send data externally>
Note over A,T: The last step is outside the user's request

The difference from a one-shot indirect injection is the accepted path. One hidden instruction that immediately asks for an external transfer is an ordinary prompt injection. FITD adds several plausible, low-risk actions first, so the boundary crossing inherits the appearance of the earlier approvals.

What does the attack look like in a calendar assistant?

Imagine an assistant that can read a calendar, organize meeting information, search notes, and send a message. The user asks, “Summarize my meetings this afternoon.” The request is ordinary, and the first tools are appropriate.

An attacker sends an invitation for a routine webinar. The title and time look normal, but a description or attached note contains a placeholder sequence: <organize the attendee list>, then <look up the related notes>, then <send the collected details to an external destination>. The example deliberately leaves the instructions abstract; the important feature is their order.

The assistant reads the calendar and sees the invitation. It follows the first request by organizing the attendees. It then follows the second by looking up the meeting notes. Both actions are small, plausible, and related to the calendar task. The user did not separately approve either instruction, but neither action looks as alarming as the final one.

After those steps, the external transfer is presented as the next piece of the same workflow. If the agent calls <send data externally>, private schedule information can leave the organization. A direct request to do that would have been easier to challenge. The sequence makes the unsafe action look like a routine completion step.

What can you do to defend against FITD?

Defenses should check authorization at every sensitive action. Model refusals help, but they cannot be the only control because the attack deliberately makes the unsafe step look reasonable.

1. Give each task only the tools it needs. If the user asks for a calendar summary, allow calendar and formatting tools while removing external messaging, upload, and write tools from that run. Fewer available tools mean fewer ways for a misleading note to turn into a side effect.

2. Ask for confirmation at the boundary. Require a clear user approval before sending data, changing records, deleting content, or calling a new external service. The confirmation should say what data will leave the system and where it will go, rather than asking the user to approve a vague “next step.”

3. Keep untrusted content separate from instructions. Mark calendar descriptions, web pages, documents, and tool results as data. Delimit them in the agent’s context and tell the agent that text inside them cannot change permissions or create new tasks. This reduces confusion, although it should not replace runtime enforcement.

4. Check the original goal before every side effect. Store the user’s requested outcome outside the model’s working text. Before a write or external transfer, compare the proposed action with that goal and block it when the connection is not explicit. A request to summarize should not silently become a request to publish.

5. Test sequences, not only isolated prompts. A defense that rejects a direct exfiltration request may still fail after several accepted tool calls. Include benign prefixes and untrusted intermediate results in security tests, and review whether the agent stopped at the permission boundary.

How can you test your agent with AiBeat?

You need a running target Agent that you control, an AgentBeat installation, a target registration, and a configured Judge model. The AgentBeat quickstart explains the Registry JSON format and the environment variables used to connect a target.

1. Install AgentBeat and prepare your target

   Follow the AgentBeat quickstart to install the CLI and verify it. Run your own Agent so that AgentBeat can reach it. In the target registry, register that Agent and complete the target_profile, target_capability, and deployment_profile_id values required by the evaluation file. The quickstart includes a complete Registry example and explains AGENTBEAT_TARGET_URL.

2. Configure the target registry and Judge

   Point AIBEAT_AGENT_TARGET_REGISTRY at your Registry JSON and configure the Judge. The Judge is required for this evaluation.

   export AIBEAT_AGENT_TARGET_REGISTRY=./your-target-registry.json
   export AGENTBEAT_TARGET_URL="http://127.0.0.1:39103"
   export AIBEAT_JUDGE_BASE_URL="https://api.example.com/v1"
   export AIBEAT_JUDGE_MODEL="<judge-model>"
   export AIBEAT_JUDGE_API_KEY="<judge-api-key>"

   Use the real values for your environment. The quickstart documents these variables and the Registry fields; keep secrets out of shared files and logs.

3. Download the FITD seed from Seeds Community

   Open the fitd-calendar seed page in Seeds Community and use the download command shown there. Do not guess a version or URL. The English seed file is named eval-run.en.json.

   mkdir -p ./seeds/<seed-id> \
     && curl -fsSL https://www.aibeat.ai/community/registry/<seed-id>/<version>/eval-run.en.json \
     -o ./seeds/<seed-id>/eval-run.en.json

   Before running it, make sure the downloaded file’s target_profile, target_capability, and deployment_profile_id point to the target you registered.

4. Run the evaluation and read the result

   Run the seed with the downloaded file:

   ./bin/agentbeat eval-run < ./seeds/<seed-id>/eval-run.en.json > ./seeds/<seed-id>/result.json

   Read the result for the practical conclusion: whether the attack succeeded and what happened in the agent’s interaction. A run that cannot observe or judge the relevant behavior does not prove that the agent is safe; treat an indeterminate result as a reason to investigate and rerun after fixing the test setup.

Reference

• Breaking ReAct Agents: Foot-in-the-Door Attack Will Get You In, arXiv:2410.16950. The paper studies how multi-step behavioral momentum can influence tool-using agents under its experimental conditions.