Traditional vs. Agent Frameworks: Same Dimensions, Different Liabilities
Oct 16, 2026 · @disc
Why the agent shift is a liability shift
Agent frameworks move the most important decisions in your software from build time to runtime, and from your developers to a model. Every control you built for traditional software assumed the opposite.
In traditional software, a developer wrote every route, wired every API, and shipped every behavior change through code review and a release. If an auditor asked “why did the system do that?”, the answer was in the code.
In an agent framework, the LLM decides at runtime which tools to call and in what order. It reads tool schemas and picks for itself. It stores and retrieves its own memory. Its behavior changes when someone edits a system prompt, with no redeployment. It can hand work to other agents.
The dimensions are the same: control flow, tool orchestration, memory, behavior change, and coordination. The philosophy is completely different. So are the risks, the governance obligations, and the evidence you will need when something goes wrong.
This post walks through each dimension and shows what breaks, which threats move in, what ISO/IEC 42001, ISO/IEC 27001, the EU AI Act and the NIST AI RMF expect, and what you must log to prove control. The rule that ties it together: never let model output be the only thing standing between an instruction and a privileged action.
The five dimensions, and what each one breaks
1. Control flow: from build time to runtime
Traditional software is deterministic. You can enumerate its paths, test them, and point to the line of code behind any outcome. An agent’s path is chosen per request by a model reading untrusted input. You cannot test every path, because the paths do not exist until the model invents them.
The risk is goal hijack. A document, email, web page or ticket the agent reads can carry instructions that redirect it. The model cannot reliably tell your instructions from an attacker’s, because both arrive as text.
The control is to separate planning from execution. Let the model propose; let a deterministic policy layer outside the model decide whether the action is allowed. Add action budgets, a kill switch, and human approval for anything irreversible.
2. Tool orchestration: the schema is the attack surface
A hardcoded API call only does what the developer wrote. An agent reads tool names, descriptions and parameter schemas and chooses for itself. That means the tool description is an instruction to the model. A malicious or compromised MCP server can poison it, and a legitimate tool can be called with parameters nobody intended.
The risks are tool misuse, unexpected code execution, and supply-chain compromise through third-party tools, skills and MCP servers.
The controls are a registry of approved tools with pinned versions, typed and validated parameters, authorization checked before every execution, sandboxing for code, and a supplier review for every MCP server. A tool the agent can discover at runtime is a dependency you never assessed.
3. Memory: persistent context is persistent compromise
In traditional software, the developer decides what is stored and where. In an agent framework, memory is tiered (in-context, vector, episodic) and the framework decides what is retrieved. A poisoned entry written once can steer every future session.
Memory also creates privacy and retention obligations most teams miss. Personal data in a vector store is still personal data. A deletion request must reach the embeddings, the episodic store, and the caches, not just the source table.
The controls are provenance and trust labels on every memory write, write authorization, expiry dates, quarantine and rollback, and a retention period for each memory tier.
4. Behavior modification: “no redeployment needed”
This is the line on the slide that should worry a CISO most. In traditional software, changing behavior requires a code change, review, testing, and a release. In an agent framework, editing a system prompt or a tool description changes production behavior immediately.
That convenience bypasses change management entirely. A prompt edit can remove a guardrail, widen a tool’s use, or change who the agent serves, with no ticket, no approval, and no record of the version that made a disputed decision.
The control is to treat prompts, tool descriptions and agent configuration as production code. Version them, require approval, test them before release, and log which version was live for every action. A material change should also trigger a fresh risk assessment.
5. Multi-agent coordination: accountability gets lost in delegation
Traditional microservices talk through contracts the developer designed. Agent frameworks let one agent call another as a tool, in hierarchies that can be built or changed at runtime. Each hop is a trust boundary, and each one can launder authority.
The risks are insecure inter-agent messages, privilege abuse through delegated credentials, and cascading failures where one agent’s error is amplified by the next. The “confused deputy” problem returns at scale: a low-privilege agent asks a high-privilege agent to do what it cannot.
The controls are a unique identity for every agent, short-lived scoped credentials, authenticated and validated messages, bounded delegation depth, circuit breakers, and a trace ID that follows a request across every agent it touches.
At a glance: same dimensions, different liabilities
| Dimension | Traditional software | Agent framework | What breaks | Control that must live outside the model |
| Control flow | Developer defines every route at build time | LLM chooses tools and order at runtime | Untestable paths; goal hijack through untrusted content | Policy engine authorizes every action; action budgets; kill switch |
| Tool orchestration | Hardcoded endpoints | Agent reads schemas and selects tools | Tool descriptions become instructions; tool misuse; MCP supply chain | Approved tool registry, pinned versions, parameter validation, sandboxing |
| Memory | Developer-managed sessions and databases | Tiered memory with framework-managed retrieval | Poisoned memory persists; erasure requests miss embeddings | Provenance labels, write authorization, expiry, rollback |
| Behavior change | Code change and full redeployment | Edit the prompt or tool description, no redeploy | Change management bypassed; no record of the live version | Prompts and configs versioned, approved, tested, and logged |
| Multi-agent coordination | Developer-designed microservices | Agent-as-tool and hierarchical orchestration | Confused deputy; spoofed messages; cascading failures | Per-agent identity, scoped credentials, bounded delegation, circuit breakers |
The agentic threat model
All ten risks in the OWASP Top 10 for Agentic Applications enter through one of the five dimensions above. Use this table to see where each threat comes in and which control blocks it.
| OWASP risk | Enters through | What it looks like | Primary control |
| ASI01 Agent goal hijack | Control flow | A retrieved document tells the agent to email the data room index to an outside address | Isolate untrusted content; validate actions against policy, not model intent |
| ASI02 Tool misuse | Tool orchestration | A legitimate export tool is called with a destination nobody approved | Destination allowlists; authorization before execution; transaction limits |
| ASI03 Identity and privilege abuse | Multi-agent coordination | An agent reuses a user’s long-lived token or a shared service account | Unique agent identity; short-lived scoped credentials; access reviews |
| ASI04 Agentic supply chain | Tool orchestration | A third-party MCP server or skill update changes behavior overnight | Approved registry; version pinning; supplier assessment; fast revocation |
| ASI05 Unexpected code execution | Tool orchestration | Natural language becomes a shell command or SQL query | Sandboxing; command allowlists; no secrets in the execution environment |
| ASI06 Memory and context poisoning | Memory | One poisoned entry steers every later session | Provenance labels; write authorization; quarantine and rollback |
| ASI07 Insecure inter-agent communication | Multi-agent coordination | A spoofed or replayed message triggers a downstream action | Authenticated channels; message integrity; schema validation |
| ASI08 Cascading failures | Multi-agent coordination | One agent’s error multiplies across a chain of agents | Circuit breakers; rate limits; workflow timeouts; blast-radius limits |
| ASI09 Human-agent trust exploitation | Behavior change | A confident answer gets a reviewer to approve an unsafe action | Show provenance and uncertainty; second approver for high-impact actions |
| ASI10 Rogue agents | Control flow | An agent acts outside its objective or hides what it did | Behavioral baselines; anomaly detection; independent monitoring; kill switch |
Two design patterns should be treated as critical findings by default: an agent approving its own high-impact action, and an agent controlling the monitoring or logging that watches it. Both turn an attack into an invisible one.
Scope the controls to the agent’s risk. An assistive agent that drafts text needs far less than one that touches production systems, regulated data, or money. Tier your agents first, then apply the full baseline to the ones that can act on their own.
What the frameworks expect from agents
None of the major frameworks has an “agent” chapter, but each one already covers the five dimensions once you map them. The gap is rarely the standard; it is that agent controls are left to engineering and never written into the management system.
| Dimension | ISO/IEC 42001 | ISO/IEC 27001 | EU AI Act | NIST AI RMF |
| Control flow | A.6.2.6 operation and monitoring; A.9 responsible use | A.8.16 monitoring activities | Art. 14 human oversight; Art. 15 accuracy, robustness, cybersecurity | MANAGE 4.1 post-deployment monitoring |
| Tool orchestration | A.10 third-party and customer relationships | A.5.19–5.22 supplier security; A.8.28 secure coding | Art. 15 cybersecurity | GOVERN 6 third-party risk |
| Memory | A.7 data for AI systems, including A.7.5 provenance | A.5.34 privacy and PII; A.8.10 information deletion | Art. 10 data governance (high-risk) | MAP 4 risks from data and third-party components |
| Behavior change | A.6.2.5 deployment; Cl. 6.3 planning of changes | A.8.32 change management | Art. 12 logging across the system’s lifetime | MEASURE 3 tracking risk over time |
| Multi-agent coordination | A.5 impact assessment; Cl. 6.1 risk treatment | A.5.15 access control; A.8.2 privileged access | Art. 26 deployer obligations | GOVERN 1.6 AI system inventory |
Three points matter most for agent programs.
Inventory the agents, not just the models. ISO 42001 and NIST GOVERN 1.6 both expect an inventory of AI systems. For agents, each entry should record the tools, credentials, memory stores, connected agents and MCP servers it uses. A model inventory alone misses most of the attack surface.
A prompt change is a change. ISO 27001 A.8.32 and ISO 42001 A.6.2.5 do not exempt configuration that happens to be written in English. Auditors will ask how a system prompt reached production and who approved it.
The EU AI Act clock still applies. The AI Omnibus deferred stand-alone high-risk obligations to 2 December 2027, and Annex I systems to 2 August 2028. Article 50 transparency duties largely still apply. An agent that makes or shapes consequential decisions about people will need 2027-grade logging and oversight, and logs cannot be created retroactively.
Need a hand?
DISC InfoSec helps B2B SaaS and financial services firms build evidence that holds up under ISO/IEC 27001, ISO/IEC 42001, the EU AI Act, and the NIST AI RMF. We led Virtual Data Room through ISO/IEC 42001 Stage 2 certification on the first attempt, including its AI log retention and records management standard.
Book a free 30-minute call at calendly.com/hd-deurainfosec, or email info@deurainfosec.com https://deurainfosec.com
- Traditional vs. Agent Frameworks: Same Dimensions, Different Liabilities
- The Controls Are Still Being Written: Governing AI When the Technology Outruns the Audit
- If Your Frontier Model Vanished for 3 Weeks, Would Your Business Stop?
- The Evidence Lifecycle: Which Organizational Events to Log for Liability — and How Long to Keep Them
- 14 Months to Comply. 12 Months of Work. The High-Risk AI Playbook Nobody Has Started
