AI agents are moving from chat windows into the systems where work happens. They read email, prepare meetings, update tickets, search documents, interact with browsers, post messages, run code, and come back later to continue a task. That makes them useful. It also changes the security model.

Before launching Wingman, Emergent engaged Straiker to evaluate the agent under realistic adversarial conditions. Wingman is an AI assistant that users interact with through channels such as iMessage, WhatsApp, and Telegram. It connects to user-authorized services — email, calendars, chat, documents, repositories, CRMs, project systems — and builds on the same orchestration and sandbox infrastructure that powers Emergent's app builder.

Those capabilities raise one urgent question: what happens when attacker-controlled content reaches an agent with access to your authenticated services?

The answer depends less on what the model says and more on what the system allows: where the instruction came from, what data it can touch, where it can send or write information, and whether that flow matches the user’s intent.  We tested whether malicious instructions planted in ordinary external content could induce the agent to use legitimate permissions in ways the user did not intend. The assessment helped Emergent harden controls before public launch and produced lessons that apply to any team building connected, action-taking AI systems. Emergent has published a companion post on how it built Wingman’s defenses.

In this model, the agent can propose an action, but a separate control layer has to decide whether that action is allowed.

This post describes the threat model, the attack patterns we exercised, the control classes that mattered, and the recommendations we believe agent builders should apply before deployment. It intentionally omits exploit payloads, attacker identifiers, internal session data, and implementation details that would make active abuse easier.

Background on Wingman by Emergent

Wingman is a personal AI agent that lives in WhatsApp, iMessage, and Telegram. It runs in the background, learns your preferences, and handles the work related tasks that build up over your day: scheduling, follow-ups, daily briefings, research, project coordination. Unlike chatbots you have to prompt, it acts on its own, and can take action based on schedules and incoming messages.

That places Wingman in a different risk category from a traditional chatbot. A hostile email, calendar invite, shared document, issue comment, social message, or linked web page is no longer inert text. It can become context for a model that holds authorized tool access.

In a conventional application, the security question is usually whether an attacker can bypass authentication or exploit a software flaw. For a connector-enabled agent, an additional question matters: can an attacker route instructions through content the agent is expected to process, then induce the agent to use the user’s own authorized capabilities?

The engagement used a controlled dual-organization environment with realistic corporate data, connected integrations, simulated external attacker identities, and ordinary user prompts. That setup lets us evaluate the full agent loop: content ingestion, provenance, model reasoning, tool calls, action approval, scheduler behavior, sandbox boundaries, and final side effects on connected systems.

Threat Modeling Connector Agents

Our threat model treated every connector as three things at once:

This framing is important because a connector-enabled agent is not only reading content. It is deciding whether content should influence action. The risk is rarely confined to the connector where the attack begins.

An attacker might inject through a shared document, ask the agent to read a CRM, and send the output through email. They might start with a calendar invite, link to a web page, pull data from a mailbox, and publish it to a public social channel. The agent is the bridge between systems, and that bridge needs policy, provenance, confirmation, sandboxing, and auditability.

Scheduled tasks were treated as their own trust boundary. Background execution changes the risk profile because the user may not be present when the agent processes content, creates a recurring job, or performs a sensitive action. A one-time injection can become a durable capability if the scheduler accepts it without strong intent checks.

The same framing applies to browser-mediated workflows. Once an agent loads a page, fills a form, or follows a deep link, the page becomes part of the agent’s working context and the browser becomes both a source and a potential sink.

What Straiker Tested for Emergent

We designed scenarios around realistic user behavior:

• Checking an inbox
• Reviewing newly shared documents
• Catching up on notifications
• Preparing for a meeting
• Cleaning up project tasks
• Reviewing social messages
• Handling overdue work before time off

The user prompts in these scenarios are benign. The adversarial content came from external artifacts the agent might naturally retrieve while completing them.

Across the engagement, we tested 8 proof-of-concept exploits using 6 distinct techniques against more than 18 connected integrations, spanning 7 delivery vector categories. Every exploit was triggered by a single, benign-sounding user prompt.

The assessment covered multiple delivery vectors:

• Email bodies, subjects, forwarded threads, and structured task-like content
• Shared documents, drive files, spreadsheets, wiki pages, notes pages, and second-hop links
• Calendar invitations and meeting-prep pages
• Issues, mentions, repositories, and linked runbooks
• Social messages and mentions, including defanged or obfuscated links
• Browser-mediated web flows, forms, embedded widgets, and local-looking tools
• Scheduled and recurring task creation, including content those tasks would later process

We evaluated outcomes, not model text alone. A prompt injection is security-relevant when it produces an unauthorized side effect: data exfiltration, cross-connector data movement, permission changes, public posting, destructive execution, artifact creation, or durable automation.

A model repeating malicious text is one class of failure. An agent using a mailbox, a calendar, a CRM, a social account, or a code-execution environment to complete an attacker-controlled workflow is a different class of risk entirely.

Attack Patterns Straiker Exercised

The most important result of the engagement was not any single payload. It was the recurring pattern underneath them: untrusted content can look like work, and models are not reliable authorities for deciding when that work should become action.

Each of the following classes exercised a different combination of source, sink, and trust boundary. The control point is the flow, not the model’s confidence in the task.

Socially Engineered Connector Content

The most effective attacks did not look like “ignore previous instructions” prompts. They looked like ordinary business process:

• Marketing handoffs
• Audit checklists
• CI runbooks
• CRM cleanup tasks
• Support workflows

This is the practical challenge for agent security. The agent is designed to help with work, and attackers can make malicious instructions resemble work. A control that asks the model to “ignore suspicious content” cannot reliably distinguish a hostile audit checklist from a legitimate one. That decision has to be made by policy: what source introduced the instruction, what system it wants to touch, and whether the requested action matches user intent.

Cross-Connector Pivoting

Several scenarios used one connector as the injection surface, a second connector as the data source, and a third connector as the exfiltration or action channel.

The general shape was:

Injection in A → Read from B → Write to C

These combinations spanned documents, CRMs, mailboxes, calendars, repositories, social accounts, and project tools.

The security boundary is therefore not “is this connector trusted?” but “is this flow consistent with the user’s intent and the authority of the source content?” That question can only be answered outside the model. A connector may be trusted in isolation, but the flow still has to prove it should exist.

Multi-Hop Trust Laundering

In multiple scenarios, the first artifact contained only a benign-looking link. The actual malicious instructions appeared after the agent followed the link to a second hop.

Defenses that inspect only the first artifact can miss the real payload. If an agent follows a link from an untrusted email, document, invite, issue, or social message, the fetched content needs to inherit the original trust context.

Otherwise, the attacker has laundered the instruction through a second hop, and any first-hop classifier or warning has already fired and been satisfied. The security boundary cannot stop at the first artifact; it has to travel with the agent across every hop, connector, and tool call.

Scheduled-Task Persistence

Autonomy amplifies risk. We tested whether a malicious instruction could create or influence recurring work so that an attack continued after the initial prompt and after the user moved on.

For connected assistants, scheduler creation and scheduler mutation are high-impact actions. A recurring task is not only a convenience feature; it can become persistent if it is derived from attacker-controlled content.

The policy should re-check at execution time as well, since the data the schedule will process did not necessarily exist when the schedule was created.

Obfuscation and Browser-Mediated Exfiltration

We evaluated payloads that used:

• Structured data
• Encoding schemes
• Defanged URLs
• Fake validators
• Local-looking web tools
• Browser interactions that appeared innocuous to the agent

The goal was to see whether sensitive data could be transformed or moved through channels that would not look like direct connector exfiltration.

This pattern reinforces a broader point: agent security needs controls around browser sessions, web forms, and outbound requests from agent-driven pages, not only around first-party connectors.

Destructive and Integrity-Focused Actions

Not every meaningful attack is data theft. We also tested destructive and integrity-focused outcomes:

• Deleting public content
• Granting persistent access to attacker-controlled identities
• Running untrusted code in environments connected to user data
• Creating misleading artifacts
• Manipulating systems in ways that could harm a user’s organization or reputation

For agents, “sensitive action” needs to include:

• Writes
• Deletes
• Permission grants
• Public posts
• Code execution
• Recurring tasks
• Cross-system artifact creation

In other words, sensitive actions should not be defined only as outbound communications. They should include any tool call that can change state, create durable artifacts, expand access, or affect how an organization is represented externally.

What Strong Remediation Looked Like

Emergent’s response was strongest where fixes moved beyond prompt hardening. Prompts and model instructions are useful, but they are not a complete security boundary.

Durable controls need to make unsafe tool calls difficult or impossible even when malicious content reaches the model.

The highest-value remediation themes followed from that architecture:

The architectural principle underneath these patterns is simple:

Treat model output as a proposal, not as authority.

A separate control layer decides whether the proposed action is allowed, whether confirmation is required, and whether the destination is appropriate for the data involved.

Recommendations for Agent Builders

Based on this review, we recommend the following practices for teams building connector-enabled agents:

1. Threat model the full agent loop. Include content sources, tool permissions, scheduler behavior, sandbox boundaries, and final side effects. Do not stop at prompts and responses.
2. Separate the data plane from the control plane. Email, documents, tickets, calendar invites, social messages, and web pages should be treated as data to process, not instructions to execute.
3. Carry provenance across every hop. If an agent follows a link from untrusted content, the fetched content should remain untrusted. The same applies to attachments, copied text, browser pages, transformed data, and scheduled context.
4. Constrain cross-connector flows. Reading from one system and writing to another should be reviewed against user intent, data sensitivity, source trust, destination trust, and enterprise policy.
5. Require confirmation for high-impact actions. External communications, public posts, permission grants, destructive changes, code execution, and scheduled automations should not proceed silently when derived from connector content.
6. Sandbox execution aggressively. Generated scripts and repository-sourced code should run with least privilege and without access to system paths, unrelated user files, secrets, or broad network egress.
7. Test side effects, not only refusals. Security evaluations should inspect tool calls, parameters, approvals, writes, deletes, sends, scheduled jobs, and final workspace state.
8. Build regression tests from real attack paths. Every confirmed issue should become a replayable evaluation that can catch changes in model behavior, tool behavior, connector policy, prompt design, or product controls.

Closing Thoughts

Emergent deserves credit for approaching Wingman’s launch with the right security posture. Before putting a connected agent into the hands of users, their team invited adversarial testing against realistic workflows, connected systems, scheduled tasks, browser activity, and cross-tool actions.

That matters because connected agents need to be tested as action-taking systems, not chat surfaces. The security question is not only what the model says. It is what the agent can reach, what it is allowed to do, what data it can move, and what side effects it can create.

This is the work Straiker was built for. Gartner positions Straiker with distinct offensive AI security testing capabilities for AI agents, and Straiker Ascend AI was named Best AI Security Testing Platform by The Hacker News Cybersecurity Stars Awards 2026. Both point to the same reality this assessment showed in practice: securing agents requires purpose-built adversarial testing, runtime controls, and a deep understanding of how agentic systems fail when ordinary content becomes part of the attack surface.

If you are building or deploying connected agents, test them before attackers do. Get a free risk assessment with Straiker.