Six AI agent architectures expose distinct control boundaries

At a glance

What this is: This analysis maps six AI agent architectures to the control points that matter most, showing that each archetype concentrates a different governance risk and cannot be treated with one generic policy model.

Why it matters: IAM, PAM, and NHI teams need separate controls for assistants, workflows, and autonomous agents because the same gateway, approval, and trace strategy does not fit every execution pattern.

By the numbers:

• 38% of organizations report enhanced client or customer relationships as an achieved benefit through AI initiatives, according to Deloitte.
• 42% of 600 surveyed risk and compliance professionals say human oversight is mandatory, according to Moody's.
• Multi-agent usage rose 327% in less than four months across 20,000+ organizations on the Data Intelligence Platform, according to Databricks.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% say the risk is immediate, according to SailPoint.

👉 Read TruFoundry's analysis of six AI agent architectures and control boundaries

Context

AI agent architecture determines how identity, access, and control behave in practice. A conversational assistant, a triggered workflow, and an autonomous agent may all use the same model family, but they do not share the same trust boundary, approval model, or tool exposure. That is why the primary question for AI agent governance is not what the model can do, but which runtime architecture governs its actions.

For IAM and NHI programmes, the mistake is to collapse all AI systems into one control pattern. The article’s central finding is that execution path, timing, and orchestration shape the identity problem as much as the model itself. That means the governance design has to follow the actor type and the operating plane, not the marketing label attached to the application.

TrueFoundry’s article is useful because it translates architecture into control placement, especially around gateway inspection, orchestration boundaries, and human approval gates. The starting position is typical for enterprise AI adoption: teams want speed first, then discover that governance depends on the agent pattern they actually deployed.

Key questions

Q: How should teams govern AI assistants, workflows, and autonomous agents differently?

A: Teams should govern them by runtime behaviour, not by model family. Assistants need strong prompt and response controls, triggered workflows need untrusted-input screening and narrow tool scope, and autonomous agents need separate identities, scoped delegation, and traceability across each decision. A single AI policy rarely fits all three.

Q: Why do autonomous AI systems create more identity risk than normal automation?

A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person. That makes intent less predictable and review cycles less useful. The risk increases when the system can broaden scope or trigger actions that affect data, money, or compliance.

Q: What breaks when streaming assistants rely on output guardrails alone?

A: Output guardrails cannot inspect a complete response before the user sees it when the system streams tokens in real time. That means sensitive disclosures, unsafe content, or policy violations can arrive before a check completes. Teams need a non-streaming path, buffering, or an input-only trade-off they accept knowingly.

Q: Who should be accountable for AI agent approvals and audits?

A: Accountability should sit with the human owner of the agent path, the application owner, and the identity governance process together. The agent cannot be the sole accountable subject because it is not a governance endpoint. Teams should tie approvals, logs, and access reviews to the person or team responsible for the agent’s use.

Technical breakdown

Conversational assistants and the conversation surface

A conversational assistant is governed at the interaction layer because the user and the model share a live dialogue. The main technical risk is data exposure through prompts, memory, citations, and streamed output, especially when users paste sensitive material or the assistant answers from live context. Input guardrails can inspect what enters the system, while output guardrails only work where the full response exists before display. That creates a real boundary for streaming architectures, because token-by-token delivery reduces what can be validated before the user sees it.

Practical implication: treat streaming assistants as a separate safety class and decide whether output validation, buffering, or input-only protection is acceptable.

Triggered workflows and untrusted input

Triggered workflows run when an external event arrives, which means the system executes unattended on data it did not originate. That makes the trigger payload itself the key attack surface, because prompt injection can hide inside email, file, or ticket content and steer the workflow once the model reads it. The technical controls that matter are pre-inference inspection, tight tool scope, and rate limiting. The governance question is not whether the workflow is automated, but whether the trigger data is trusted enough to drive downstream actions.

Practical implication: screen trigger payloads before model execution and limit write-capable tools to the smallest viable set.

Autonomous and multi-agent systems need explicit identity boundaries

Autonomous and multi-agent systems introduce independent planning, delegation, and sub-agent coordination, which makes execution less predictable than request-response workflows. In this model, identity has to bind not just to a caller, but to each agent role, its tool scope, and the observable trace of decisions it makes. The architecture is closer to governed delegation than to a conventional application call path. That means accountability depends on per-agent identity, scoped permissions, budget limits, and traceability across each step in the chain.

Practical implication: assign distinct identities and scoped policies to each agent role before allowing cross-agent tool use.

NHI Mgmt Group analysis

Six archetypes are not a maturity ladder, they are six different identity problems. Treating assistants, workflows, autonomous agents, and human-in-the-loop systems as one category creates policy drift, because each architecture concentrates risk in a different plane. The control point may be the conversation surface, the trigger payload, the agent identity, or the approval gate. Practitioners should map governance to runtime shape, not to the generic label "AI system".

Assumption collapse begins when teams assume access can be governed after execution starts. That assumption was designed for stable, request-based systems where identity is known before the action begins. It fails when autonomous agents choose steps, tools, and sub-agents at runtime, because least privilege is no longer fully knowable at provisioning time. The implication is that identity governance must account for decision timing as well as entitlement scope.

Gateway control is useful, but only when the architecture actually crosses the gateway. The article’s model shows that input validation, output inspection, rate limits, and logging are not universal fixes. They bind different archetypes differently, and some controls only make sense at pre-invoke or post-invoke stages. Teams should stop asking for one AI security pattern and start matching control placement to agent behaviour.

Human-in-the-loop is not a compromise architecture, it is a governance choice. The approval gate becomes the primary control when the task is too sensitive for unattended execution, but the surrounding workflow still matters. That is why this pattern often becomes the bridge between IAM discipline and AI operational reality. The right question is not how much autonomy to allow, but which decisions must remain reviewable by a person.

Named concept: architecture-to-control fit. This post is really about matching runtime archetype to the control plane that can actually govern it. The practical value is in avoiding overgeneralised AI security programmes that look complete on paper but fail at the moment of execution. Identity teams should use architecture-to-control fit as the organising principle for AI governance reviews.

From our research:

• 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.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to SailPoint research.
• That risk profile makes OWASP NHI Top 10 useful for prioritising the governance failures that recur across agent architectures.

What this signals

architecture-to-control fit: AI governance programmes will increasingly be judged on whether controls are placed where the runtime actually makes decisions. A control that works for a conversational assistant may fail completely for a triggered workflow or autonomous agent, because the attack surface shifts from the prompt to the trigger, then to the delegation chain. Teams should align policy, logging, and approval logic to the execution pattern rather than to the model brand. The same discipline maps cleanly to OWASP Top 10 for Agentic Applications 2026.

The next governance gap is not model choice, but observability across tool use, memory, and approval state. If your programme cannot say which agent touched which tool, or which step crossed a human gate, you do not yet have operational identity control for AI. That is the point at which IAM, NHI, and agentic AI governance converge into one programme.

With 80% of organisations already seeing AI agents act beyond intended scope, governance is moving from design-time concern to operational control. The teams that will stay ahead are the ones that treat agent identity as a first-class asset and tie it to traceable tool use, scoped delegation, and policy enforcement.

For practitioners

• Map each AI workload to a named architecture Classify every assistant, workflow, autonomous agent, and human-in-the-loop system by how it executes, not by which model it uses. Put the architecture label on the control register so reviewers can see where prompt, tool, approval, and trace controls should bind.
• Place guardrails at the correct execution boundary Apply input screening before the model reads trigger data, apply output inspection only where complete responses exist, and avoid assuming the same hook works for streamed and non-streamed paths.
• Assign distinct identities to agent roles Give each independently governed agent a separate principal, scoped tools, and observable traces, then restrict cross-agent delegation to the minimum needed for the task.
• Define when human approval is mandatory Reserve explicit approval gates for high-impact tool calls, and document which tasks may proceed unattended so reviewers do not turn every action into a bottleneck.
• Review logs and retention by architecture Decide which request metadata, tool traces, prompt bodies, and response bodies must be stored for each archetype, then align retention with the amount of sensitive content each system can touch.

Key takeaways

• AI agent architectures create different identity and control problems, so one security pattern cannot govern them all.
• Most organisations already see agent behaviour exceed intended scope, which makes runtime governance an immediate operational issue.
• Teams need architecture-to-control fit, separate identities, and reviewable approval points to govern AI systems safely.

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.
• Triggered Workflow: An AI-driven process that starts when an external event arrives, such as an email, file, or ticket. The work runs unattended on untrusted input, so the security problem is not just automation, but whether the trigger data can safely drive downstream actions without prompt injection or tool abuse.
• Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.
• Architecture-to-Control Fit: The principle that governance controls must match the way an AI system actually behaves at runtime. A control that protects one architecture can fail in another if the trigger point, approval model, or tool use pattern changes. This is the core design problem in AI identity governance.

What's in the full article

TruFoundry's full article covers the operational detail this post intentionally leaves for the source:

• Specific gateway enforcement points for input validation, output inspection, and logging across different agent patterns.
• Documented configuration prerequisites for streaming assistants, triggered workflows, and autonomous agents.
• The control mapping between MCP traffic, Agent Harness approval gates, and managed orchestration boundaries.
• The article's summary table and diagnostic questions for choosing the right agent architecture.

👉 TruFoundry's full article shows how the architecture map translates into gateway controls, approvals, and observability.

Deepen your knowledge

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