Six AI agent architectures expose distinct control boundaries

At a glance

What this is: This is an analysis of six AI agent architectures and the distinct control boundaries each one creates across conversation, triggers, autonomy, approvals, and scheduling.

Why it matters: It matters because IAM, PAM, and AI governance teams need different controls for different agent behaviours instead of assuming one gateway or approval model fits every deployment.

Context

AI agent architecture is the way an agent decides, acts, and waits for approval. TruFoundry’s analysis argues that the critical control question is not whether a system uses AI, but where its model calls, tool calls, and human approvals actually bind.

For identity and access practitioners, that means the governance problem changes by archetype. A conversational assistant, a triggered workflow, an autonomous agent, and a human-in-the-loop design do not share the same trust boundary, so lifecycle, authorisation, and observability controls must be matched to behaviour rather than label.

The article’s central claim is that adoption, governance, and trust improve only when the architecture fits the task. That makes the post relevant to both NHI and agentic AI programmes, because the same deployment can look safe in one operating mode and uncontrolled in another.

Key questions

Q: What breaks when teams use one control model for all AI agent architectures?

A: One model breaks because assistant, workflow, autonomous, multi-agent, HITL, and scheduled designs do not share the same timing, tool reach, or approval boundary. Controls that work for a chat assistant can fail in an unattended workflow or an autonomous loop. Practitioners need architecture-specific governance, not a single blanket policy.

Q: Why do autonomous AI agents need different identity governance than assistants?

A: Autonomous agents can decide when to act, which tools to call, and how to chain sub-tasks, so identity governance must bind to runtime behaviour rather than static user-like assumptions. Assistants are closer to conversation-bound access, while autonomous systems need scoped identity, explicit approvals, and traceable delegation.

Q: What are the signs that an AI security agent is failing governance review?

A: Common warning signs include unclear retry behaviour, no fixed scope boundaries, mixed operator intervention, and logs that cannot reconstruct each action. If the team cannot explain what the agent was allowed to do and prove what it actually did, governance is not working.

Q: What is the difference between human-in-the-loop agents and autonomous agents?

A: Human-in-the-loop agents pause for review before sensitive actions, while autonomous agents proceed through their own decision sequence without an approval gate between each step. The practical distinction is not just who is involved, but when control is exercised. That timing difference drives different governance, logging, and containment requirements.

Technical breakdown

Conversation-surface controls for assistants

A conversational assistant concentrates risk at the prompt and response boundary. The article describes user-level memory, citations, and tool use on behalf of the user, which means the primary control plane is input sanitation, output safety, and request-path governance. For streaming assistants, the important distinction is that output guardrails need a complete response, so non-streaming delivery or post-stream buffering becomes a design decision, not an afterthought. This is less about model intelligence than about where the enterprise allows untrusted text to enter and leave the system.

Practical implication: treat the conversation surface as a governed interface and decide up front how streamed output will be validated.

Triggered workflows and untrusted input

Triggered workflows run unattended when an event arrives, so the control boundary sits at the trigger payload rather than at a human review point. That matters because the inbound email, file, or ticket can carry prompt injection or malformed instructions inside content the workflow was built to process. In architectural terms, the safest posture is to separate detection on the trigger from the downstream tool surface, then constrain write-capable actions so a single poisoned input cannot fan out into broad execution. Auditability also changes here, because the trace must capture what the workflow saw and did, not just that it ran.

Practical implication: screen trigger payloads before model execution and minimise tool write-scope for unattended workflows.

Autonomous and multi-agent governance boundaries

Autonomous and multi-agent systems move the control boundary from a single prompt-response cycle to a chain of decisions, tool selections, and delegated sub-tasks. That creates a governance problem that is partly NHI and partly agentic: the system needs explicit identity, scoped tools, budgets, and traceability because execution paths are no longer fully predictable in advance. Multi-agent designs also introduce attribution questions, since each independently governed role may need its own identity rather than sharing one caller principal. The result is that control is not only about permission, but about containing recursive task expansion and proving which agent did what.

Practical implication: assign distinct identities, scope tools per role, and require traces that preserve attribution across agent-to-agent delegation.

Threat narrative

Attacker objective: The objective is to turn a legitimate AI agent architecture into a broader execution path than governance intended, so tool use and downstream actions outgrow the original trust boundary.

1. Entry occurs when an attacker or malicious input reaches the architecture through the conversation surface, trigger payload, or tool-connected workflow.
2. Credentialed or delegated access is then abused when the system is allowed to call tools, persist memory, or move from one agent role to another without enough scoping.
3. Impact follows when the chosen architecture permits unintended actions, such as uncontrolled tool use, policy bypass, or broad downstream execution across the gateway plane.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance fails when teams treat architecture as cosmetic: The article is right to reject a hierarchy across agent types, because the control boundary changes with execution shape, not branding. A conversational assistant, a triggered workflow, and an autonomous agent do not inherit the same approval logic or monitoring depth. Practitioners should map each architecture to its own boundary conditions before they choose controls.

Access review processes assume access persists long enough to be reviewed: That assumption is designed for stable entitlements, not for agents that acquire tools, delegate tasks, and complete work across compressed runtime windows. When execution timing and tool reach are architectural variables, governance cannot be built on a single review cadence. The implication is that access governance must move closer to issuance and invocation, not later in the cycle.

Task-scoped identity is now a control primitive, not an implementation detail: The most consequential point in the article is that identity, tools, and approvals have to be bound to the way the agent actually behaves. Shared principals collapse attribution, while overly broad tool grants collapse containment. Practitioners should treat distinct agent roles as separately governed subjects, especially where multi-agent orchestration is in play.

One gateway plane can centralise calls, but it cannot erase behavioural differences: The article’s architecture model shows why central routing helps without solving governance by itself. Centralised mediation improves visibility, yet assistants, workflows, autonomous agents, and HITL systems still need different policy logic. The practical conclusion is that platform consolidation should simplify enforcement, not flatten the distinctions that make enforcement meaningful.

Runtime governance gap: The named concept here is the gap between how an AI system is governed at design time and how it actually behaves at runtime. That gap widens when approvals, tool use, or state carry forward across sessions. Teams need to recognise that the same model can be safe in one archetype and unsafe in another, so architecture selection is itself a control decision.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

The governance mistake this article exposes is architectural flattening. Teams often buy a single control story for “AI agents” and then discover that assistants, triggers, and autonomous loops need different enforcement points. The programme signal is clear: classify the behaviour first, then choose the control.

Runtime governance gap: When the same gateway mediates both simple assistants and multi-step autonomous systems, the boundary that matters is not the transport layer but the runtime decision loop. That is where identity, tool scope, approvals, and traceability must be made explicit if teams want defensible control.

For practitioners, the next step is to align controls with execution timing. If an agent can act without a person in the loop, treat that as a design problem for issuance, approval, and observation rather than as a simple extension of existing access policy.

For practitioners

• Map controls to archetype, not to model label Classify each deployment as assistant, triggered workflow, autonomous agent, multi-agent system, HITL design, or scheduled agent before assigning approval, logging, and tool-scoping rules.
• Separate trigger screening from tool execution For unattended workflows, inspect the inbound payload before the model reads it and keep write-capable tools narrowly scoped so one injected instruction cannot fan out.
• Assign distinct identities to independently governed roles Do not collapse multiple agents into one caller principal when their decisions, tool reach, or accountability differ, because shared identity destroys attribution and containment.
• Design streamed output handling deliberately If an assistant streams responses, choose between non-streaming delivery, client-side buffering with validation, or input-only protection with clear acceptance of post-delivery detection.
• Constrain autonomy with scoped approvals and observability Use approval gates, budgets, and trace metadata where agents can plan or delegate independently, so execution remains observable even when it is not fully predictable.

Key takeaways

• AI agent architecture determines the control boundary, so governance has to follow behaviour rather than model branding.
• Assistants, triggered workflows, autonomous loops, and human-in-the-loop designs fail in different ways when treated as one category.
• The strongest control patterns in this article are scoped identity, trigger screening, approval gating, and runtime traceability.

Key terms

• AI Agent Architecture: The runtime pattern that determines how an AI system receives inputs, makes decisions, uses tools, and hands work off. In governance terms, architecture matters because it defines where identity checks, approvals, and logging must happen, and whether those controls can be applied before or after execution begins.
• Control boundary: The line that defines who can administer, observe, and change a system. For NHI and IAM programmes, the control boundary matters because auditors and risk teams care about where authority sits, not just where the software runs. Clear boundaries make assurance easier; blurred ones create governance debt.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.