Beyond the Perimeter: Securing Agentic AI Workflows and Autonomous Multi-Agent Swarms

Introduction

A chatbot answers a question. An agent decides what to do next, then does it. A swarm of agents does that across a dozen systems before anyone checks in. As systems gain more autonomy, more decisions can be delegated from a human operator to the software workflow. Each step also makes an old question harder to answer: once an AI system can read your data, call your APIs, create tickets, modify records, send messages, run code or hand work to another agent, where exactly does the security boundary sit?

That question does not have one correct answer. It depends on what the agent can do, how much autonomy it holds, what it can touch, and what controls sit between its decisions and anything irreversible. Risk here is a function of capability, autonomy, access, environment and controls, not a property of "AI agents" as a category. This is an architectural perspective on how to think through that question before an agent gets production access, not a claim that every agent is dangerous or that any single control makes one safe.

Traditional application security assumed that humans initiate most meaningful actions and software executes predefined logic. Agentic AI changes that control plane. An agent can interpret a goal, plan a sequence of steps, call tools, retrieve data, use memory, delegate work to another agent, and decide between steps how to proceed, adapting as it goes. When several agents collaborate, the security boundary stops being a single line and becomes distributed across models, prompts, tools, APIs, memory, identities, data stores, an orchestration layer and the messages agents exchange with each other.

As an architectural way of framing it, worth treating as a perspective rather than a settled doctrine: the perimeter is no longer just where the network ends. It is wherever an agent can exercise authority. The goal is not to eliminate autonomy. It is to make autonomy bounded, observable, attributable, policy-controlled, reversible where possible, properly authorized, and continuously evaluated.

Key Takeaways

• Agentic AI security is the discipline of controlling, authorizing and observing AI systems that plan and execute actions, not only generate text.
• The security perimeter moves from the network edge to wherever an agent can exercise authority: a tool call, an API, a delegated task.
• Prompt injection becomes a privilege-escalation problem once a model with tool access can be manipulated into taking an unintended action.
• Multi-agent systems create new trust relationships between agents, not only between a user and a system, and those relationships need their own identity and authorization model.
• Least agency, bounding what an agent may do, under what conditions, for how long, is a useful extension of least privilege for autonomous systems.
• Human-in-the-loop reduces risk but is not a complete security strategy by itself; its value depends on what the reviewer actually sees and can act on.
• Frameworks such as the OWASP Top 10 for Agentic Applications and the NIST AI Risk Management Framework provide structured guidance, not legal compliance or a security guarantee.

Why Agentic AI Changes the Security Model

Most security models built over the last two decades assume a fairly stable division of labor. A human decides to do something. Software executes that decision through code paths someone wrote and tested in advance. A chatbot, in this sense, is a conservative addition to that model: it reads a prompt and produces text, and a person decides whether to act on what it said.

An agent breaks that division in a specific way. Give a language model a goal, a set of tools and permission to call them, and it stops being a system that only produces information. It starts planning a sequence of steps, choosing which tool to call next based on what the last one returned, holding state across that sequence, and in many designs deciding on its own when the task is finished. A multi-agent workflow extends this further: one agent hands a subtask to another, which may call its own tools, retrieve its own data and reach its own conclusions before handing control back.

None of this makes an agent an independent actor in any legal or philosophical sense. It is software executing a model's output against a defined set of capabilities. But the practical effect is real: decisions that used to be made by a developer at design time are now being made at run time, by a probabilistic model, based on context that can include retrieved documents, prior tool outputs and instructions from other agents. That shift, from predetermined logic to in-context decision-making, is why securing an agent is a different engineering problem than securing a conventional application, even though both are ultimately software.

Table 1. Traditional AI vs. Agentic AI vs. Multi-Agent Systems

The New Attack Surface of Agentic AI

Securing an agent by hardening only the model, through fine-tuning, a system prompt or an output filter, addresses one layer of a much larger surface. In practice, an agentic system is a stack, and a gap in any layer can undermine the controls built into the others. A tight tool allowlist does nothing to stop a compromised orchestrator from calling the right tool for the wrong reason, and a jailbreak-resistant system prompt does nothing to stop a poisoned document from issuing instructions through the retrieval layer.

Table 2. The Agentic Attack Surface

From Prompt Injection to Privilege Escalation

Prompt injection is usually introduced as a content problem: text gets into a model's context that makes it say something it should not. That framing made sense when the worst outcome was an off-brand response. It stops being adequate the moment the model can call a tool.

Direct prompt injection is a user typing an instruction designed to override the system prompt or stated task. Indirect prompt injection is more consequential in agentic systems: a model retrieves a document, an email, a web page or a support ticket, and treats whatever instructions are embedded in that content as having the same standing as the user's actual request. The agent did not choose to read a hostile instruction. It read a document it was told to read, as part of a task it was told to do, and the document happened to contain one.

What turns this from an annoyance into a security incident is what the agent is authorized to do next. A model that only produces text can be tricked into saying something wrong. A model with tool access can be tricked into calling a tool it was authorized to use, with parameters an attacker effectively chose. That can turn prompt injection into a privilege-escalation problem when the agent can exercise meaningful authority through tools.

This pattern shows up in a few recognizable shapes: a confused-deputy scenario, where an agent uses its own legitimate authority on behalf of an untrusted party that could never act directly; excessive agency, where an agent holds more capability than the task in front of it requires, so a manipulation that should have been harmless becomes expensive; and unsafe delegation, where one agent hands a subtask to another without carrying forward the restrictions on the original task, effectively turning a narrow permission into a broader one somewhere downstream.

None of this requires a sophisticated adversary. It requires an agent that reads untrusted content, holds standing authority to act, and has no independent check between "the model decided to do this" and "the action happened." The defense is architectural, not a smarter prompt: treat every retrieved input as untrusted regardless of source, separate instructions from data wherever the underlying system allows it, and never let the model's own stated justification be the only gate in front of a consequential action.

When Agents Become a Distributed Trust Problem

A single agent raises questions about what it is allowed to do. A set of cooperating agents raises a second question that is easy to miss: what should one agent be allowed to assume about another?

In many early multi-agent implementations, the default answer is "whatever it says." Agent A tells Agent B that a task is approved, that a user already consented, that a budget exists, and Agent B proceeds. That works until Agent A is wrong, has been manipulated, or is impersonated by something that is not Agent A at all. A line worth holding onto: an agent should not gain authority simply because another agent told it to act. Authority should come from a verifiable source, not from a message that claims it.

Making that hold in practice means treating agent-to-agent communication the way a distributed system treats communication between services it does not fully trust. Each agent needs its own identity, not a shared service account borrowed from the orchestrator. Depending on the architecture, message authentication, integrity protection and replay resistance may be appropriate. Delegation needs explicit, narrower scope at each hop: if Agent A is authorized to read customer records for support purposes and delegates a subtask to Agent B, Agent B should receive exactly the permission needed for that subtask, not a copy of everything Agent A can do. Where an action matters enough, the system should be able to show, after the fact, which agent took it, under whose delegated authority, and on what evidence, which is what makes meaningful audit and non-repudiation possible in a workflow with no human in the loop at every step.

This is not a claim that multi-agent systems are inherently less safe than single-agent ones. It is a claim that they introduce relationships that single-agent security thinking does not cover, and those relationships need the same discipline applied to any other service-to-service trust boundary.

The Principle of Least Agency

Least privilege asks what an identity can access. It is a mature, well-understood idea in identity and access management, and it is necessary but not sufficient for agents, because an agent's risk is not only about what it can reach. It is about what it can do, on its own initiative, without anyone checking first.

A useful extension, offered here as a proposed architectural principle rather than an established industry standard, is least agency: an agent should hold the minimum autonomy needed to complete its current task, for the shortest time necessary, using the narrowest set of tools, within explicit limits on what it can do without approval.

In practice, least agency shows up as concrete design decisions: scoping an agent's permissions to the specific task it was invoked for rather than its general role; issuing short-lived, task-bound credentials instead of standing access; defining an allowlist of permitted actions rather than relying on a denylist of forbidden ones; setting hard limits on transaction size, spend or blast radius; separating environments so a development or test agent cannot reach production data; and setting explicit time limits so a credential or session does not outlive the task it was created for.

None of this requires treating every agent as equally dangerous. A read-only research agent summarizing public documentation warrants a different posture than an agent that can issue refunds or modify infrastructure. The point of least agency is to make that distinction explicit and enforced, rather than something that depends on nobody misusing a capability nobody bothered to restrict.

Tools Are the Real Execution Boundary

Tools are usually where a model's output stops being a suggestion and starts being an action. A database write, a payment, an email sent to a customer, a CRM record updated, a cloud resource provisioned, a file modified, code executed, a browser driven through a web application: each is a point where a probabilistic decision made inside a context window reaches into a system that has no way of knowing the request came from a language model rather than a person.

That does not make the tool layer the single highest-risk part of an agentic system. It makes it the layer where impact gets realized, which is different: a flaw in the retrieval or orchestration layer can be just as serious, but it usually needs a tool call downstream to turn into actual damage.

Treating tools as the execution boundary they are means applying the rigor a well-run API applies to any caller it does not fully trust. Each tool needs its own authentication, separate from the user's session, so the agent acts under its own accountable identity. Each call needs authorization specific to the action and data involved, not a blanket "this agent can use this tool." Input parameters need schema and value validation before execution, and the tool's output needs validation too, since a compromised or malfunctioning downstream system can feed bad data back into the agent's next decision. Rate limits and transaction caps bound what a single session or runaway loop can do. Higher-impact actions benefit from sandboxing or a dry-run mode before anything irreversible happens, and from a human approval step sized to the actual risk. Every call needs logging detailed enough, who, what, why, with what parameters, what result, to be reconstructed later without guessing. Where an action can be undone, a rollback or compensating action should exist and actually be tested, not assumed to work the one time it is needed.

Memory and RAG: The Hidden Trust Boundary

Memory and retrieval tend to get treated as data-engineering problems: build the pipeline, chunk the documents, tune the embeddings, measure recall. They are also where a surprising amount of agentic risk hides, because both create a channel through which content an agent did not generate becomes part of what it believes and acts on.

Long-term memory lets an agent carry context across sessions, which is useful, and also means a single successful manipulation, a false fact written to memory, a poisoned preference, a fabricated prior approval, can keep influencing behavior long after the original interaction ended. Retrieval-augmented generation pulls documents from a vector database or search index into the model's context, and if that store contains content from untrusted or lightly reviewed sources, a document can carry an embedded instruction much like a malicious email can.

A separate and easy-to-miss failure mode is authorization mismatch: retrieval systems are often built to find the most relevant content, not to check whether the requesting user or agent is actually allowed to see it. A document scoped to one tenant or access level can surface in a response simply because it was the best semantic match, unless retrieval authorization is enforced as its own step rather than inherited from the underlying index's access controls. The principle worth holding onto: retrieval authorization should be enforced independently of what the model asks for, checked against the actual permissions of the requester, not assumed safe because the content lives in a company-controlled store. The same discipline applies to tenant isolation in multi-tenant RAG systems, where cross-tenant leakage is one of the more damaging and least visible ways this layer fails.

Multi-Agent Swarms: More Capability, More Trust Relationships

There is a real trade-off here, and it runs in both directions. Splitting work across specialized agents can produce genuine benefits: a research agent, a planning agent and an execution agent each do one thing well instead of one generalist doing everything adequately; tasks run in parallel instead of serially; a failure in one agent does not necessarily take down the others; and complex work decomposes into pieces that are each easier to test and reason about.

The same decomposition that produces those benefits also multiplies what can go wrong. More agents means more communication paths, each a potential point of manipulation or failure. More agents means more privilege relationships to track, since each agent's permissions and each delegation between them needs its own review. A failure in one agent can propagate to the ones depending on its output, sometimes silently, since a downstream agent has no inherent way to know an upstream one was manipulated. And the practical cost of observability and policy enforcement rises with every agent added, because tracing a decision now means following it across process and trust boundaries, not just through one model's context window.

None of this argues against multi-agent architectures. It argues for sizing the governance layer to match the architecture, rather than letting the number of agents grow faster than the team's ability to say, with confidence, who can do what, under what authority, and how to verify it afterward.

Conceptual architecture

                 Human / Business Intent
                          |
                 Policy & Risk Engine
                          |
                     Orchestrator
                          |
        -----------------------------------
        |                |                |
     Agent A  <----->  Agent B  <----->  Agent C
        |                |                |
        -----------------------------------
                          |
                  Tool / API Gateway
                          |
        -----------------------------------
        |          |            |         |
      Data       SaaS         Cloud      External
                                          Systems

  Identity · Authorization · Policy · Observability ·
  Auditability · Threat Detection · Human Oversight
          (span every layer above)

Agent Identity: Every Agent Needs a Security Context

It is tempting to treat an agent as an extension of whichever user or service invoked it, borrowing that identity rather than establishing its own. That shortcut is also where a lot of accountability quietly disappears, because once an action is logged under a shared or borrowed identity, there is no clean way to answer "which specific agent, running which specific task, actually did this."

A workable model gives every agent a unique workload identity, distinct from the human user, the service account and any other agent it works alongside. That identity needs its own authentication, its own scoped authorization, and credentials isolated from whatever else runs in the same environment, so compromising one agent does not hand over everything else nearby. Where one agent acts on behalf of a user or another agent, the system should be able to show the chain of delegated authority, not just the final action.

This points at a distinction worth keeping separate in how the system is designed: "who is the agent" is an identity question, answered once when the agent is provisioned. "What is the agent authorized to do right now" is an authorization question, answered fresh at every consequential action, based on the current task, the data involved and current policy, not a static role assigned at setup. Collapsing these into one check, identity equals authorization, is a common shortcut and a common source of agents doing things that were technically within their role but wrong for the specific moment.

Policy Before Action

A conceptual flow is useful here, less as a specification than as a way of checking whether a given architecture actually evaluates policy where it needs to:

Intent -> Risk classification -> Identity verification -> Authorization
   -> Tool policy -> Data policy -> Approval requirement -> Action
   -> Verification -> Logging -> Outcome

The detail worth noticing is where this flow puts the checks: at the boundary of the action itself, not only at the boundary of the prompt. A system that validates a user's input and then lets the model's subsequent tool calls run unchecked has only secured the entry point. Each step in an agent's plan, each tool call, each data access, each delegation to another agent, is its own decision point, and a policy engine that runs once at the start of a task cannot account for a plan that changes based on what the agent learns along the way. Evaluating policy at every action boundary costs more than evaluating it once, and it is the difference between a system that can say no to a specific action and one that can only say no to a conversation.

Human-in-the-Loop Is Not a Security Strategy by Itself

"Keep a human in the loop" is the most common answer to agentic risk, and it is incomplete often enough to be worth examining directly. A human approval step is only as good as what the human can actually evaluate in the time they have.

Its effectiveness depends on specifics that general advice tends to skip: whether the information presented to the reviewer is enough to understand what the agent is actually proposing, not just a summary that sounds reasonable. Whether the reviewer can realistically grasp the downstream consequence of approving it. How many approvals one person handles in a day, since volume is what turns careful review into reflexive clicking. Whether approval happens early enough to prevent harm or late enough that reversing course is already expensive. Whether the action can be undone if the approval turns out to be wrong. And whether there is a real escalation path when a reviewer is unsure, rather than a binary approve-or-reject choice under time pressure.

It helps to think in terms of three distinct postures rather than a single checkbox. Human-in-the-loop, where a person approves before execution, fits higher-risk or hard-to-reverse actions where the delay is worth the protection. Human-on-the-loop, where a person monitors and can intervene or roll back afterward, fits higher-volume, lower-individual-risk actions where upfront approval for every instance would be impractical. Human-out-of-the-loop, fully autonomous execution within pre-approved bounds, fits narrow, well-tested, reversible actions where the cost of delay outweighs the marginal benefit of a checkpoint. None of these three is correct by default. The right posture depends on the action's reversibility, its blast radius, and how well the system's other controls already bound what can go wrong.

Observability: If You Cannot Reconstruct the Decision Path, You Cannot Operate the System Confidently

An agent that behaves unexpectedly is not primarily a model problem to debug. It is an investigation, and investigations need evidence. The question that matters after something goes wrong is rarely "was the model capable of this." It is "what did it see, what did it decide, and why was it allowed to act on that decision."

Answering that reliably requires logging built for reconstruction, not just for metrics: the prompts and context assembled at each step, the tool calls made and their parameters, the identity each action ran under, the policy decisions that approved or blocked each step, the documents or data retrieved, messages exchanged between agents, the actual results of each action, failures and retries, any human approvals involved, which model and version produced which decision, and timestamps and correlation or trace IDs that let the whole sequence be stitched back together.

This is also where a real trade-off deserves to be stated rather than waved past: the same logs that make an incident reconstructable can contain exactly the sensitive data the system was supposed to protect, customer records, credentials accidentally surfaced in a tool response, personal information pulled in during retrieval. Comprehensive logging and data minimization pull in different directions, and the answer is not to log everything indiscriminately. It is deliberate design: redact or tokenize sensitive fields before they are written to logs, separate the audit trail from raw payload storage where possible, and apply access controls to the logs themselves that match the sensitivity of what they might contain.

Designing for Containment and Reversibility

Prevention will not catch everything, which is exactly why containment and reversibility need to be designed in rather than assumed. Sandboxing and isolated execution limit what a compromised or malfunctioning agent can reach even if an upstream control fails. Transaction boundaries and dry-run modes let a consequential action be previewed or tested against a staging target before it touches anything real. Approval gates and kill switches give a human or an automated monitor a way to stop a specific action or an entire workflow once something looks wrong. Circuit breakers, rate limits and spend caps bound the damage a runaway loop or repeated bad decision can do before anyone notices. Compensating actions and rollback paths, a refund to reverse an erroneous charge, a corrective record to undo a bad write, reduce the cost of a mistake that does get through.

It matters to be direct about the limits here: not every action an agent can take is reversible. An email that has been sent, a message delivered to a customer, a decision that already shaped someone's experience, cannot be fully undone by any system design. That is precisely the argument for weighting prevention and approval more heavily for actions in that category, and for treating "can this be undone if we are wrong" as one of the first questions asked about any action an agent is given authority to take, not an afterthought handled once something has already gone wrong.

Security Testing for Agentic Workflows

Agentic systems need testing that goes beyond the accuracy and quality evaluation most AI teams already run, extended into the specific ways autonomy and tool access can fail: threat modeling the workflow itself, not just the model, to find where an attacker or a malfunction could gain outsized effect; adversarial evaluation that specifically probes for prompt injection, both direct and through retrieved content; testing whether a tool can be invoked with parameters outside its intended use, and whether authorization checks hold under that pressure; testing for data leakage across tenants, sessions and users, particularly through retrieval and memory; testing whether one agent can be impersonated by another, and whether a receiving agent properly verifies identity and authority before acting on a message; testing whether memory or a knowledge store can be poisoned with content that influences later behavior; testing whether a sandboxed execution environment actually holds under an attempt to break out of it; testing whether policy enforcement can be bypassed through an unexpected sequence of steps rather than a single malicious input; failure-injection and resilience testing that deliberately degrades a dependency or tool response to see whether the system fails safely or fails by guessing; and structured red-team exercises that bring these together against a realistic deployment, run inside authorized, isolated test environments against systems the team owns or has explicit permission to test, never against production systems or third parties without authorization.

None of this is exotic once it is named. Most of it is the same testing discipline already applied to any system with real authority over real data, extended to account for the fact that the thing making decisions in the middle of the workflow is a model rather than fixed code.

A Practical Agentic AI Security Architecture

Pulling the preceding sections together into something closer to a reference architecture helps when the conversation moves from "what could go wrong" to "what do we actually build." A representative stack, moving from where a request enters the system to where it reaches the real world: the user or business request; an identity layer authenticating the human, the service and the agent separately; a policy engine evaluating risk and authorization before and during execution; an orchestrator sequencing tasks and enforcing workflow-level policy; the agent runtime where planning and tool selection happen; a model gateway that routes to the right model and applies version control and basic output checks; a tool gateway authenticating and authorizing each tool call independently of the agent's own identity; a data access layer enforcing row- and document-level permissions rather than trusting the query that arrives; memory and retrieval systems with their own authorization and provenance checks; sandboxed execution for anything that runs code or touches infrastructure; a human approval layer sized to the risk of the action; an observability layer tracing the full decision path; security analytics watching for anomalous patterns across agents and sessions; and incident response processes that assume, correctly, something will eventually get through the layers above.

Table 3. The Agentic Security Control Plane

A C-Suite Checklist Before Giving an AI Agent Production Access

The following is written as questions a leadership team can actually ask, with a sense of what a credible answer should be backed by. Vague confidence on any of these is a sign the answer needs more work, not reassurance.

Table 4. Executive Readiness Checklist

The Governance Layer: Security Is Not Only a Technical Problem

Every control described so far assumes someone decided it was necessary, someone is accountable for it working, and someone reviews whether it still makes sense as the system changes. That is a governance function, not an engineering one, and it tends to be the piece missing even in technically well-built systems.

Governance here means a fairly concrete set of things: clear ownership of the agent's behavior in production, not a diffuse sense that "the AI team" is responsible. An explicit statement of risk appetite, what level of autonomy is acceptable for which categories of action, decided deliberately rather than inherited from whatever the first version shipped with. Documented policies that tie back to the controls described earlier, rather than controls that exist without a stated rule they enforce. A clear approval authority for granting an agent new capabilities, so scope expands through a decision rather than accumulated small changes nobody reviewed together. An incident response process that specifically accounts for autonomous actions, not just traditional outages. Change management for prompts, tools and permissions, the same discipline applied to any other production change. Periodic re-evaluation, since a system safe at launch can drift as models are upgraded, tools are added, or usage shifts. And documentation thorough enough that someone other than the original builder can understand what the system is authorized to do and why.

Frameworks are worth placing carefully here rather than treated as one undifferentiated category. Industry guidance such as the OWASP Top 10 for Agentic Applications and the NIST AI Risk Management Framework, including its Generative AI Profile, provide structured, widely referenced ways to think about these risks. They are voluntary technical frameworks, not law, and following them is good practice rather than a compliance guarantee. Legal frameworks such as the EU AI Act impose actual obligations in specific circumstances, determined by jurisdiction, role and risk classification, and aligning with a technical framework does not by itself satisfy a legal requirement. Keeping that distinction clear matters: a team that treats OWASP or NIST alignment as equivalent to legal compliance has assessed its engineering maturity, not its legal exposure.

What "Production-Grade Agentic AI" Should Mean

"Production-grade" gets used loosely enough in AI marketing that it is worth defining through specific engineering characteristics rather than treating it as a label a vendor applies to itself. A system worth calling production-grade in this sense demonstrates bounded autonomy; least privilege and least agency enforced together; explicit identity for every agent and every delegation; policy enforcement at action boundaries, not only at the prompt; secure and independently authorized tool access; real data isolation between tenants and users; end-to-end observability sufficient to reconstruct any consequential decision; continuous evaluation rather than a one-time pre-launch review; resilience to dependency failure that fails safely rather than silently; incident response built for autonomous actions specifically; human governance with clear ownership; cost controls that prevent a runaway loop from becoming a runaway bill; and security testing that specifically covers the agentic failure modes described above.

This is a working description, not an official certification or an industry-standard checklist with a governing body behind it. Treat it as a bar to measure a specific system against, not a label to claim.

The Strategic Question for Leaders

The question worth asking about agentic AI stopped being "can we build this" a while ago. A working AI agent can often be assembled much faster than the security architecture required to operate it safely at scale. The harder questions sit on the other side of that milestone: what authority are we actually giving it. What happens when it is wrong, not in theory but in the specific way this system is likely to be wrong. Can we see what it did, in enough detail to explain the decision to someone who was not in the room. Can we stop it, mid-task, without taking down everything around it. Can we explain, after the fact, why it was allowed to take the action it took. And can we recover, cleanly, when an autonomous workflow fails in a way nobody anticipated.

None of these questions have a universal answer, and none are fully solved by a single product, framework or vendor claim. They get answered, case by case, by the architecture built around a specific agent doing a specific job with specific access. Organizations moving from AI demos to autonomous production systems increasingly need architecture that treats security, governance and observability as part of the system itself, designed in from the first version, not as controls added after something has already gone wrong.

Disclaimer: This article is provided for educational and technical information only. It does not constitute legal advice, cybersecurity certification, regulatory certification, or a guarantee of compliance or security. Specific regulatory obligations and security decisions depend on the applicable system, jurisdiction, use case and organizational context.

FAQ

Sources & Further Reading

1. OWASP GenAI Security Project, Agentic Security Initiative, "OWASP Top 10 for Agentic Applications (2026)": https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
2. OWASP GenAI Security Project, main site: https://genai.owasp.org/
3. NIST, "AI Risk Management Framework" (AI RMF 1.0, January 2023): https://www.nist.gov/itl/ai-risk-management-framework
4. NIST, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile" (NIST AI 600-1, July 2024): https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
5. EUR-Lex, Regulation (EU) 2024/1689 (the EU AI Act): https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Related reading

This article sits alongside the topic pages on Agentic AI Security and Production AI, and two related write-ups: The Demo-to-Production Gap and The Agent Card Problem.