The FinOps Reference Architecture

Summary

Security discussions about "AI agents" stay abstract unless they're grounded in a real architecture. This workshop uses one running example — a FinOps (cloud financial operations) multi-agent application — as a checkpoint after each subsequent chapter: identity (Chapter 3), data protection (Chapter 4), platform hardening (Chapter 5), and runtime observability (Chapter 6) are each shown applied to the same diagram. This chapter introduces that architecture, breaks down what an agent is actually made of, and frames the four systemic challenges that recur across every domain in the Agentic AI Security Framework from Chapter 1.

Core concepts

What an agent is made of

Every agent in the reference architecture is built from three core components:

• Model (LLM) — powers reasoning and language understanding.
• Instructions — define the agent's goals, behavior, and constraints. Instructions take one of three forms: declarative (a prompt-based agent combining model configuration, instructions, tools, and natural-language prompts), workflow (an agentic workflow expressed as YAML or code that orchestrates multiple agents or triggers actions on criteria), or hosted (a containerized agent created and deployed in code, hosted by a platform like Azure AI Foundry).
• Tools — let the agent retrieve knowledge or take action against real systems.

This matters for security because each component has a different attack surface. The model can be jailbroken. The instructions can be overridden by injected content. The tools can be invoked with the wrong arguments or invoked when they shouldn't be invoked at all. Treating "the agent" as one undifferentiated thing to secure misses that these are three distinct control points.

The four systemic challenges

Across every domain in the security framework, four challenges show up repeatedly:

• Agent sprawl & resource access — 82% of leaders expect to use agents in the next 12–18 months to meet demand for workforce capacity (Microsoft Work Trend Index Survey, 2025).
• Data oversharing & leaks — 80% of leaders cited leakage of sensitive data as their main concern (First Annual Generative AI Study: Business Rewards vs. Security Risks, ISMG, Q3 2023, N=400).
• Shadow AI, new threats & vulnerabilities — 88% of organizations are concerned about indirect prompt injection attacks (Gartner, "How to Secure Custom-Built AI Agents," 17 March 2025).
• Regulatory compliance — 55% of leaders lack understanding of how AI is and will be regulated and are seeking guidance (ISMG, Q3 2023).

Architecture discussion

The reference architecture is a three-agent FinOps application:

• FinOps supervisor / planner agent — the central coordinator. It manages user queries and orchestrates the two subordinate agents below.
• Cost analysis agent — uses historical invoice and accounts-receivable data to gather and analyze cost data for a specified time range.
• Cost optimization agent — uses a data warehouse (Data Explorer / Synapse Analytics) to produce actionable cost-saving recommendations.

The exercise: spot the weaknesses

Before introducing any controls, the workshop pauses on this diagram and asks participants to identify security weaknesses unassisted. The two weaknesses the workshop specifically calls out are memory and context poisoning (an agent's short-term or long-term memory being corrupted by adversarial input) and prompt injection, both direct (UPIA) and indirect via retrieved content (XPIA). Both are revisited with concrete controls in Chapter 5.

Key security considerations

• An agent's blast radius is the union of its tools' blast radius. The cost optimization agent's access to a data warehouse is a data-exfiltration path even if the agent itself was never intended to expose that data directly.
• Orchestration is a trust relationship. The supervisor agent trusts output from two subordinate agents. If either subordinate is compromised or manipulated, the supervisor propagates that without necessarily re-validating it.
• Credentials and secrets sitting next to agent code are a standing risk, independent of whether the agent is currently under attack — this is why identity (Chapter 3) is addressed before data protection (Chapter 4) in this workshop's sequence.
• The four systemic challenges are not independent. Agent sprawl makes oversharing harder to audit; shadow AI makes sprawl invisible; regulatory uncertainty means organizations often can't tell which controls are mandatory versus best-practice.

Recommended practices

1. Diagram every multi-agent system down to the level in this chapter — supervisor, subordinates, credentials, and data stores — before evaluating its security posture. Vague architecture diagrams hide vague responsibility.
2. For every tool an agent can call, ask: what is the worst single action this tool allows, and does the agent's instruction set actually need it?
3. Treat orchestration hand-offs (supervisor → subordinate → supervisor) as trust boundaries that deserve their own validation, not silent pass-through.
4. Use the four systemic-challenge stats as a lightweight way to prioritize: if your organization can't yet answer "how many agents do we have" (sprawl), that's the domain to fix first, before investing heavily in the others.

Technologies referenced

• Azure AI Foundry — hosts the FinOps agents as pro-code, containerized deployments.
• Azure Data Explorer / Synapse Analytics — backing data warehouse for the cost optimization agent.
• Retrieval-Augmented Generation (RAG) — used by the cost analysis agent to ground responses in invoice and cost data.