Notifications
Clear all
Topic starter
12/06/2026 9:50 pm
TL;DR: Agentic AI security now has to cover prompt injection, tool misuse, context poisoning, and agent-to-agent exploitation because systems can browse, call APIs, and make sequential decisions, according to Lasso Security. Traditional appsec and data protection models are no longer enough once the system can act mid-task and compound risk across tool chains.
NHIMG editorial — based on content published by Lasso Security: AI Security Best Practices: How to Build Secure AI Workflows
Questions worth separating out
Q: How should security teams govern AI agents that can browse, call APIs, and act independently?
A: They should treat those systems as governed identities with runtime risk, not as passive applications.
Q: Why do agentic AI workflows break traditional least-privilege models?
A: Because least privilege is often defined at provisioning time, while agents make decisions at runtime across multiple steps.
Q: What breaks when prompt injection or context poisoning affects an AI agent?
A: The agent can act on malicious instructions that were never part of the original request.
Practitioner guidance
- Inventory every AI agent and shadow workflow Build a live inventory of agents, tools, integrations, and delegated sub-agents so security teams can see what is actually running.
- Enforce runtime least privilege on every tool call Restrict each agent to the minimum tool set required for the task and verify every write, export, or API invocation at runtime.
- Validate retrieved content and tool responses continuously Inspect documents, feed outputs, and API responses for hidden instructions before the agent can act on them.
What's in the full article
Lasso Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of agentic workflow hardening across retrieval, tool use, and delegated execution paths
- Detailed discussion of static, dynamic, and high-agency red teaming modes for AI systems
- Operational examples of runtime guardrails and intent-based controls in production workflows
- Expanded mapping of AI security practices to governance, compliance, and audit evidence
👉 Read Lasso Security's guide to secure AI workflows in the agentic era →
Agentic AI security controls: are your workflows actually governed?
Explore further
25/06/2026 5:29 pm
Runtime security, not static policy, is now the control plane for agentic AI. Once an AI system can choose tools, sequence actions, and continue without human approval, the old model of configuring permissions at deployment is no longer sufficient. Agentic behaviour changes in session, so governance has to follow execution rather than assume it can be frozen in advance. For practitioners, this means the decisive control is continuous enforcement across the whole interaction.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent performs an unauthorized action?
A: Accountability should sit with the organisation that designed the workflow, assigned the permissions, and failed to govern execution. In agentic systems, responsibility cannot be pushed to the model alone because the surrounding identity, tooling, and monitoring decisions determine what the agent can do. Auditable logs are essential for proving that chain.
👉 Read our full editorial: AI security for agentic workflows now depends on runtime controls
