AI agents vs apps comes down to one property: where the control flow lives. A vibe-coded app fixes its logic in code and calls a model at set points, so the model is a bounded component. An AI agent hands the control flow to the model, which decides at runtime which tools to call, in what order, and when to stop. That single difference decides almost everything a governance function cares about, because an app has an enumerable decision surface while an agent produces a distribution over possible runtime paths that you can sample but never fully list. For regulated financial-services firms, that is the difference between assurance evidence that is cheap and static and assurance evidence that is expensive and continuous.
- The real choice is not agent versus app, it is deterministic control flow versus emergent control flow, and that property drives cost, auditability, and risk.
- Apps are governed from static artifacts (code, config, scopes). Agents force the assurance burden down into runtime telemetry and a governed data plane.
- In an agent, guardrails often live as sentences in prompts and tool descriptions, which the model can be talked out of following. The OWASP Top 10 for Agentic Applications (December 2025) formalises the resulting risks.
- Prefer an app or a human-gated agent as four amplifiers rise: consequential decisioning, autonomy, external exposure, and reproducibility. Reserve bounded autonomy for genuinely open tasks.
- App take-on is a solved service. Agents have no fixed code to deploy, so the answer is an Agent Manifest plus instrument-in-place monitoring, keeping data in the firm's perimeter with zero egress.
Across regulated firms, the same scene is repeating. A business team, an IT group, or an outside consultant assembles an AI system in days, demos it, and asks to ship it. Increasingly that system is called an agent, a self-routing workflow that picks its own tools. The configuration looks trivial and the demo is compelling, so the pull to deploy is strong. Some of that pull is genuine capability and some of it is fear of falling behind. The agent market reflects the momentum: MarketsandMarkets values it at roughly $7.84 billion in 2025, rising to about $52.62 billion by 2030, and Gartner projects that 40 percent of enterprise applications will include task-specific agents by the end of 2026, up from under 5 percent in 2025. The question is not whether agents are coming. It is which problems deserve one, and how to keep the firm in control when it does.
01 · The core distinctionWhat is the difference between an AI agent and a vibe-coded app?
The difference that matters for governance is where the orchestration lives. In a vibe-coded app, the sequence of steps, the branch conditions, the systems that get called, and the points where a model is consulted are all authored in code before the software runs. The model is powerful but bounded. In an AI agent, the model is the orchestrator: given a goal and a set of tools, it plans its own route, reads each result, and decides what to do next until it judges the task done.
This framing does not say apps never use model-based routing, and it does not say agents are undisciplined by nature. A vibe-coded app can route between branches with a model, and a well-built agent can be tightly constrained. The point is where the boundary is drawn and, critically, in what medium it is expressed. In an app the boundary is code and configuration. In an agent the boundary is, to a large degree, natural language.
02 · The assurance gapWhy are AI agents harder to govern than apps?
Governance runs on evidence, and each architecture yields a different kind. An app is comparatively easy to assure because its decision surface is readable: branches, downstream calls, credential scopes, and interfaces can be inspected directly, which maps to cheap, strong, static evidence. Change control is clean because behaviour only changes through a code change that leaves a diff, a review, and a deploy record. Because the only non-determinism sits inside bounded model calls, those calls can be pinned, logged, validated against a schema, and even cached. The old problem of a single number acquiring conflicting versions as it passes through many systems stays tractable.
An agent degrades each of those properties. Its static artifacts, the prompt, the tool allowlist, the model binding, are necessary but they systematically under-describe what it will do, because the behaviour is generated at runtime. The evidence that actually answers what did it do, and was it allowed to has to come from runtime telemetry and from checks at the point where the agent touches data. Agents do not merely carry more risk. They shift the cost of proof from inexpensive static artifacts to expensive continuous observability. That is a concrete, non-ideological reason agents cost more to govern.
03 · Tools and guardrailsWhat is a tool, and why do agent guardrails live in prompts?
A tool is a capability the agent can invoke: a function that queries a database, sends an email, calls a pricing service, executes code, or reaches an external system, increasingly through a standard interface such as the Model Context Protocol. But a tool is not only the capability. It is accompanied by a natural-language description of what it does and when it should be used, and it is that description the model reads in order to decide whether and how to call it.
For how a governed hand-off between Claude and enterprise data works in practice, see our guide to running MCP in the enterprise.
This is the crux, and it is easy to miss. In an app, the rule only refund up to the authorised limit is a line of code that cannot be argued out of enforcing. In an agent, the equivalent rule frequently lives as a sentence inside a tool description or a system prompt, such as use this tool only for refunds within policy. The guardrail has moved from an enforced control into an instruction the model is asked to follow. Whether it holds depends on the model, the surrounding context, and any adversarial text the agent happens to ingest.
In an app the guardrail is a control. In an agent the guardrail is often a sentence. That relocation is the single most consequential fact about governing agents.
04 · The threat surfaceWhat are the security risks of AI agents?
The security community has formalised the prose-guardrail problem. In December 2025 the OWASP GenAI Security Project published the Top 10 for Agentic Applications, the first widely adopted taxonomy aimed specifically at autonomous systems, developed with more than 100 security experts and endorsed by organisations including NIST, Microsoft, and NVIDIA. Several of its categories are direct expressions of the problem.
| Risk (OWASP ASI, 2026) | Why it exists when guardrails are prose |
|---|---|
| Goal hijacking (ASI01) | The agent cannot reliably tell a legitimate instruction from a malicious one embedded in data it reads, so an attacker can rewrite the objective itself, not just a single output. |
| Tool misuse (ASI02) | An authorised tool is driven to a harmful end through unsafe composition or excessive execution, despite every individual permission being valid. |
| Identity and privilege abuse (ASI03) | Agents inherit or share broad, long-lived credentials. The fix is to treat each agent as a first-class non-human identity with short-lived, task-scoped access. |
| Supply-chain exposure (ASI04) | Compromised tools, external tool servers, or dynamic prompt templates enter the trust boundary. Connections should be allowlisted, manifests signed, and dependencies pinned. |
| Unexpected code execution (ASI05) | Agents that generate and run code can be steered into executing attacker-influenced instructions unless execution is sandboxed and arguments validated. |
These are no longer theoretical. Prompt injection now underpins most agentic failures in production, and OWASP maps it to six of the ten categories, because a model treats the system prompt, the user request, and any retrieved text as one undifferentiated input. Real incidents followed through the first half of 2026, catalogued in OWASP and vendor reporting: a widely used model-gateway package was briefly backdoored on a public registry and pulled roughly 47,000 times in a three-hour window before detection, and disclosed vulnerabilities against popular coding agents showed that an allowlist of approved commands could be turned into the very mechanism of attack, and that an agent's own output could redraw the boundary of its sandbox. The recurring lesson is that autonomy amplifies a single weakness into a cascading one, because the agent acts on the compromised instruction at machine speed with no human in the loop.
05 · Making agents governableHow do you govern an AI agent that has no fixed code to deploy?
Because an agent has no single reviewable code artifact, the first step to governing one is to reconstruct an artifact from its parts. We call this the Agent Manifest: an explicit decomposition of the agent into the elements that determine its behaviour, each mapped to the tier of evidence that can substantiate it and the assurance mode appropriate to that tier. The manifest is what turns an opaque, self-routing workflow into something an assurance function can take on.
This is the same evidence discipline Clarista applies to AI-built apps: continuous compliance monitoring that regenerates the audit trail on every change.
The manifest makes the asymmetry with apps concrete. For an app, most take-on evidence is static, cheap, and strong. For an agent, the static artifacts are necessary but incomplete, so the evidence that answers what did it do, and was it allowed to has to come from telemetry and from governed-plane checks where the agent touches data. Underneath the whole approach sits a single construct: declared-versus-observed divergence. Take-on captures what the agent was declared to do; monitoring captures what it actually did; and the distance between them is the risk. An app can diverge too, but only through a change that leaves a diff. An agent can diverge with no diff at all, through a model update, a prompt edit, a shift in retrieved context, or an unsafe tool composition.
06 · ObservabilityHow do you monitor AI agents in production?
For an app, modest logging around the bounded model calls, added to readable code and configuration, is close to sufficient. For an agent, step-level tracing is not optional. Because the same input can trigger a different tool sequence on each run, a pass-or-fail health check tells you almost nothing. The minimum viable signal is a full, replayable trace of every model call, tool call, retrieval, and sub-agent invocation, with inputs and outputs captured at each step.
A large and maturing market now provides this. Tracing and evaluation platforms such as LangSmith, Langfuse, Arize Phoenix, MLflow, and Braintrust, along with the LLM-observability modules now built into general application-monitoring suites, capture step-level traces, cost, and latency, and increasingly converge on open standards, notably the OpenTelemetry generative-AI semantic conventions and the OpenInference instrumentation built on them. The market itself is young and moving fast: analyst estimates put LLM observability at roughly $2 billion in 2025, and one Gartner figure reported in trade press holds that only about 15 percent of generative-AI deployments instrument observability today, with a forecast reaching 50 percent by 2028. Treat those numbers as direction, not precision.
The essential distinction for a governance function is what these tools do and do not solve:
- What they give you is a transcript. They answer what did the agent do, and they are very good at it. Debugging, cost control, and regression testing all sit here.
- What they do not give you is a verdict. They do not, on their own, answer was the agent allowed to do that, because they carry no model of the firm's policy, entitlements, or regulatory obligations. Observability is a precondition for governance, not a substitute for it.
This gap is why data residency matters here. Sending production traces, which for a financial agent contain client data, prompts, and decisions, to a third-party observability cloud can itself be a compliance event. Self-hostable, standards-based instrumentation, with evidence pulled through into a plane the firm already controls, is the safer posture for this sector.
07 · Platform choiceWhich agent platform should financial firms use?
Choosing to build an agent is also choosing an operating model for it. The 2026 market divides cleanly, and the division has direct governance consequences.
| Managed enterprise platforms | Open frameworks and SDKs | |
|---|---|---|
| Examples | Microsoft Copilot Studio and Agent Framework, AWS Bedrock AgentCore, Google Vertex AI Agent Builder, OpenAI's agent platform, Salesforce Agentforce, ServiceNow, IBM watsonx Orchestrate | LangGraph, CrewAI, the OpenAI and Anthropic agent SDKs, Google ADK, Microsoft Semantic Kernel, LlamaIndex, Pydantic AI |
| Who owns control | The agent inherits identity, audit, data residency, and service levels from a vendor tenant. | Your team owns deployment, observability, and governance end to end. |
| Governance posture | Procurement-friendly and governed by default, but the controls are the vendor's and data often transits the vendor's plane. | Maximum control and the ability to keep data in place, at the cost of building the assurance layer yourself. |
| Typical FS fit | Breadth: broad, lower-stakes internal use where a vendor's controls are acceptable. | Depth: high-stakes, data-sensitive use where the firm must own the boundary. |
Two notes for regulated buyers. First, most serious programmes run both, a managed platform for breadth and a framework for the high-stakes core. Second, platform-native governance is real, but it is the platform's governance, answering to the vendor's model of control, residency, and audit. For the depth cases that dominate financial services, the durable position is to keep data in place on client-owned infrastructure and to impose one multi-framework governance plane over whatever platform the agent runs on. Within the open frameworks, the axis that matters most for governance is not developer ergonomics but auditability: durable state, replayable execution, and first-class human-in-the-loop checkpoints are what make an agent reconstructable after the fact. A framework chosen for how fast it produces a demo is not the same as one chosen for how well it survives an audit.
08 · The decisionWhen should you use an agent vs an app?
The routing rule is simple to state and rests on four amplifiers. As any of them rises, the case moves away from unconstrained agency and toward an app or a human-gated agent.
If the answer is an app, the path from prompt to production is what our enterprise vibe coding platform exists for, and every build passes code scanning before deploy.
- Consequential decisioning: the more the output drives an irreversible or material effect, the more determinism you want around it.
- Autonomy: the more the system acts without a human in the loop, the higher the bar.
- External exposure: the more the system ingests untrusted external content, the larger the injection surface.
- Reproducibility requirement: the more the output must be exactly reconstructable for a regulator or an audit, the less tolerant you are of runtime variation.
The honest other side is that agents earn their place when you cannot enumerate the paths, because the task space is genuinely open. Unstructured research, exception handling, and figuring out why a reconciliation broke are tasks where coding the decision tree is intractable or so brittle it fails on coverage rather than safety. Agents are also more robust to small schema or interface changes, and a single well-bounded agent can consolidate a sprawl of narrow apps, which can shrink a firm's governance inventory. Above all, agents shine as copilots: when an agent proposes and a person disposes, the human becomes the control point and the audit record is the human's decision. Agents are strong as augmentation and dangerous as autopilot.
The healthy default is a hybrid: an app-shaped skeleton with fixed orchestration and bounded model calls, reaching into constrained agency only where the task space is genuinely open, and always behind a gate for consequential action.
09 · The regulated viewWhat does this mean for financial-services enterprises?
For an RIA, an asset manager, a private-markets firm, a mid-market bank, or an insurer, the abstract argument becomes a concrete set of controls. A general agent that drafts a wrong summary is an annoyance. A financial-services agent that ingests a counterparty email, is steered by hidden text, and then moves money, changes a limit, releases material non-public information, or files a report, is a regulated event. Six control areas separate a demo from a production-ready deployment.
- Data residency and zero egress. Keep data in place on infrastructure the firm owns. Neither the agent's data access nor its observability traces should leave the perimeter. This is the single most load-bearing control for regulated AI, because it removes an entire class of third-party exposure and simplifies every downstream obligation.
- RBAC and non-human identity. Give each agent a first-class, short-lived, task-scoped identity governed by role-based access control, never a shared standing credential. Least privilege at every downstream call limits blast radius when, not if, something is compromised.
- Auditability and lineage. Capture a replayable, step-level record of every tool call and data access, with lineage back to source, so any output can be reconstructed and defended to an examiner. For agents this is the substitute for the code review you would run on an app.
- SOC 2 and ISO 27001 alignment. The controls a firm already runs for its software estate, access, change, monitoring, incident response, apply to AI systems too. Agents do not get an exception; they raise the bar on the monitoring and change-control domains in particular.
- Change control across a moving surface. Treat prompts, tool descriptions, model versions, and retrieval sources as change-controlled configuration. This is the hardest discipline to import, because these edits do not leave a diff by default, which is exactly why they need a governed pipeline that records them.
- Framework mapping. Map each system's controls to the frameworks that bind the firm, from SOC 2 and ISO 27001 to the NIST AI Risk Management Framework, the US Treasury's 2026 financial-services AI guidance, and model-risk expectations such as the successor to SR 11-7. The mapping should be live, not a point-in-time attestation, because both the system and the rules move.
10 · ClaristaHow Clarista helps financial firms ship AI to production
More than four million professionals now vibe-code apps, yet in financial services almost none reach production, because the gap between a working demo and an examinable, governed system is exactly the gap this paper describes. Clarista closes it. In one line, Clarista is the Production Layer plus the AI Data Fabric for AI apps and agents in financial services.
- AI Data Fabric. Federated access to data where it lives, with sourcing, preparation, governance, lineage, and auditable records, delivered with zero data egress on infrastructure the client owns. It is also where Clarista runs governed MCP servers that connect AI assistants to enterprise data without moving that data out of the perimeter.
- Production Layer and monitoring. Assess the risks of a vibe-coded app, deploy it, and run daily monitoring across four dimensions, App, Code, Security, and Cost, with 99.9 percent hosting and rollback. Every build passes production-hardening: static analysis, a software bill of materials, and secrets scanning. A monitoring-only bundle delivers standalone App, Code, Security, and Cost health for teams that host elsewhere.
The moat compounds. The platform is production-hardened per build, it is fuelled by governed, lineage-tracked data, and each app that lands adds to a governed estate rather than a pile of ungoverned prototypes. The proof is in production: Clarista runs ten financial-services firms live across four segments and three continents, including Gryphon Wealth, Leerink Partners, Matter Real Estate, and Edelweiss Alternatives. The company is SOC 2 Type II attested and ISO 27001 certified, and was named a WealthTech Americas 2026 winner.
You vibe code. We ship to production.
See how Clarista assesses, deploys, and monitors AI apps with zero data egress, or start with the enterprise-ready checklist.
Book a demoNo obligation. Bring a vibe-coded app or an agent you are trying to get past your control function.
FAQFrequently asked questions
What is the difference between an AI agent and a vibe-coded app?
A vibe-coded app fixes the control flow in code and calls a model at set points, so the model is a bounded component. An AI agent puts the control flow in the model, which decides at runtime which tools to call, in what order, and when to stop. An app therefore has an enumerable decision surface, while an agent produces a distribution over possible runtime paths.
Why are AI agents harder to govern than apps?
An app's behaviour is fixed in readable code, so most assurance evidence is cheap and static. An agent generates its behaviour at runtime, so its static artifacts under-describe what it does and the assurance burden shifts into runtime telemetry and a governed data plane. Agents move the cost of proof from static artifacts to continuous observability.
What are the main security risks of AI agents?
The OWASP Top 10 for Agentic Applications names goal hijacking, tool misuse, identity and privilege abuse, supply-chain exposure, and unexpected code execution among the top risks. Prompt injection underpins most of them, because an agent cannot reliably separate legitimate instructions from malicious text in the content it reads.
When should a financial firm use an agent instead of an app?
Prefer an app or a human-gated agent as four amplifiers rise: consequential decisioning, autonomy, external exposure, and reproducibility. Reserve bounded-autonomy agents for genuinely open tasks such as research or exception triage, and gate every consequential action behind a human.
How do you govern an AI agent with no fixed code to deploy?
Reconstruct a governable artifact called an Agent Manifest that decomposes the agent into its prompt, tool allowlist, tool usage descriptions, model binding, credential scope, and retrieval sources, then instrument the agent in place so its runtime behaviour becomes evidence. Governance then monitors the divergence between declared and observed behaviour.
Does agent observability keep data inside the firm's perimeter?
Not by default. Many tools send production traces, which contain client data and decisions, to a third-party cloud, which can itself be a compliance event. Regulated firms should prefer self-hostable, standards-based instrumentation and pull evidence into a plane they already control, keeping data in place with zero egress.
SourcesReferences and further reading
- OWASP GenAI Security Project, Top 10 for Agentic Applications (2026 edition, published December 2025) and the underlying Agentic AI Threats and Mitigations taxonomy. genai.owasp.org
- OWASP GenAI, State of Agentic AI Security and Governance, and Q1 2026 exploit reporting on prompt injection and supply-chain incidents (via Help Net Security). Help Net Security
- OpenTelemetry generative-AI semantic conventions and OpenInference instrumentation. opentelemetry.io
- NIST AI Risk Management Framework. nist.gov
- Market sizing from MarketsandMarkets (agent market) and Gartner adoption and observability estimates, reported in industry press. Treat analyst ranges as directional.
- Clarista, the Production Layer and AI Data Fabric for AI in financial services. clarista.io
This article is educational. It is not legal, regulatory, or investment advice. Control mappings should be validated against the firm's own obligations and counsel. Named products and platforms are cited as illustrations of a category and are not endorsements.