Notifications
Clear all
Topic starter
10/06/2026 11:26 pm
TL;DR: EchoLeak showed that Microsoft 365 Copilot could exfiltrate API keys and internal data through hidden email instructions, even after authentication and authorization succeeded, according to 1Password. The real issue is the access trust gap: identity confirms who the agent is, but not whether a runtime action still makes sense.
NHIMG editorial — based on content published by 1Password covering EchoLeak and the runtime trust gap in AI-assisted workflows
Questions worth separating out
Q: How should security teams govern AI agents that act on untrusted content?
A: Security teams should isolate untrusted content from sensitive actions, then require a fresh policy decision before any credential use, data export, or tool call that could change state.
Q: Why do AI agents complicate traditional IAM controls?
A: AI agents complicate traditional IAM because identity and authorization only prove who the actor is and what they may access.
Q: What breaks when access is valid but the action is wrong?
A: What breaks is the assumption that valid permission equals safe execution.
Practitioner guidance
- Separate content ingestion from sensitive execution Keep untrusted email, documents, and browser content in a non-executing context until the system has evaluated whether the requested action is allowed for that specific task.
- Replace standing access with task-scoped credentials Use short-lived session credentials, workload identity federation, or ephemeral certificates so agent workflows do not retain broad permissions beyond the immediate operation.
- Require action-level approval for high-risk operations Add deterministic checks before data export, credential retrieval, production changes, or external disclosure so the model cannot self-authorize sensitive steps.
What's in the full article
1Password's full article covers the operational detail this post intentionally leaves for the source:
- The specific runtime control model behind 1Password Unified Access across endpoints, browsers, and development environments
- The practical distinction between centralized governance, vaulting, and just-in-time patterns in AI-assisted workflows
- The security implications of browser-level confirmation and domain-bound autofill for sensitive actions
- The article's broader guidance on governing how authority is used after login, not just at the point of authentication
👉 Read 1Password's analysis of EchoLeak and AI agent runtime trust →
EchoLeak and AI agent runtime trust: are IAM controls enough?
Explore further
12/06/2026 5:24 am
Identity verification is not runtime safety. EchoLeak shows that a system can authenticate correctly, authorize correctly, and still produce the wrong outcome. That breaks the assumption that identity checks are sufficient once access is granted. For AI-assisted workflows, the real control question becomes whether the action still makes sense at execution time. Practitioners should stop treating successful login as evidence that the work is safe.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- In the same research, organisations maintain an average of 6 distinct secrets manager instances, which fragments governance and slows control consistency.
A question worth separating out:
Q: Who is accountable when an AI agent discloses sensitive data?
A: Accountability sits with the organisation that defined the workflow, the owner of the sensitive system, and the team that allowed the agent to act with that level of authority. Governance frameworks should treat the runtime decision chain as an auditable control point, not an opaque model output.
👉 Read our full editorial: AI agent identity needs runtime governance after EchoLeak
