Yair Finzi’s warning is simple but urgent: in the era of citizen development and GenAI, manual detection and traditional perimeter thinking can no longer contain the scale and speed of application sprawl — the real battleground has moved inside the corporate walls.
Background
Citizen application development platforms — commonly called low-code/no-code (LCNC) tools — let business users build apps, automations and now AI agents without traditional engineering resources. These platforms have delivered measurable productivity gains, but they have also shifted ownership, control and risk into the hands of non‑professional builders. The result is a fast‑growing, often unmanaged internal attack surface made of thousands of micro‑apps, connectors, and agents that can access systems, call APIs, and move sensitive data.
Meanwhile, platforms such as Microsoft Power Platform and Microsoft Copilot Studio have introduced runtime hooks and extensibility that make inline security possible — but they also expose new operational tradeoffs (latency, telemetry, fail‑open semantics) that security teams must understand and measure before they trust enforcement to third‑party or central monitors. Microsoft’s published developer documentation for Copilot Studio describes the external security webhook model (POST /analyze-tool-execution) used to intercept agent tool calls, and the platform requires implementers to expose a validate endpoint for health checks. This article synthesizes the interview claims made by Nokod Security’s CEO Yair Finzi, validates technical assertions against public platform documentation and vendor activity, analyzes operational implications, and offers a pragmatic set of controls and metrics security leaders need now.
Why the internal attack surface is the single biggest risk
The new reality: internal ≈ external
Finzi’s central thesis is that
citizen development collapses the line between internal and external threats: apps built by business users are internal by design but external in practice because they are created and shared widely, often with permissive defaults. When those apps include connectors, embedded tokens, or AI agents that reach out for context, they become powerful vectors for data exposure and misuse.
This is not theoretical. Microsoft’s governance guidance for Power Platform explicitly warns that the default “default environment” is accessible to many users and that tenants must configure Data Loss Prevention (DLP) and sharing limits to avoid oversharing and uncontrolled connector use. The documentation recommends blocking or restricting connectors, limiting sharing, and applying tenant isolation and IP firewalling to reduce data exfiltration risk.
Why this matters more than public‑facing apps
- Internal apps are numerous and often unscanned; many organizations lack inventory or continuous discovery for these assets.
- They are frequently granted broad access to systems via connectors and tokens that are easier to embed than to rotate.
- An internal misconfiguration (hard‑coded secret, overly broad sharing, or an open connector) can leak the same sensitive data as an external breach — and may travel faster because it sits behind fewer gated processes.
Finzi’s observation that “a token embedded into an app accessible to 100 employees is not a secret anymore” is a practical rule of thumb: something treated as a credential becomes de facto public when its effective access domain is broad. That converts configuration or design choices into crisis events.
The technical mechanics: how agents and webhooks change the game
What Copilot Studio (and similar platforms) changed
Copilot Studio and comparable agent platforms introduced a synchronous decision point: before an agent executes a tool (a connector call, an API invocation, a document write), the platform can package the planned step — prompt context, recent chat history, tool target and inputs — and POST it to an external monitoring endpoint for an allow/block/modify verdict. Microsoft’s developer docs explicitly define the analyze-tool-execution and validate endpoints as the integration surface for external monitors. This synchronous pattern makes
prevention possible — not just detection — because a monitor can block dangerous actions before they execute. It is the architectural change that has turned runtime enforcement from conceptual to practical.
The operational tradeoffs: latency, telemetry and fail‑open behavior
The synchronous decision loop introduces three non‑trivial constraints:
- Latency: The monitor must respond quickly enough to preserve an interactive user experience. Industry reporting and vendor integrations reference sub‑second to ~1,000 ms budget expectations; Microsoft’s public documentation emphasizes low latency for synchronous checks, and implementations in the field commonly target sub‑second p95/p99 numbers. Security teams must test these under expected load.
- Telemetry and privacy: The plan payload contains prompts and tool inputs that can include PII, intellectual property, or regulated data. Sending those payloads to third‑party monitors requires contractual guarantees about in‑memory analysis, no persistent storage, encryption in transit and at rest, and geographic residency controls where required. Industry guidance stresses demanding these assurances or using tenant‑hosted monitors for regulated workloads.
- Fail‑open semantics: Multiple community reports and vendor writeups indicate that if the external monitor times out or is unreachable, the default platform behavior — designed to preserve user experience — can be permissive (a “fail‑open” posture). That creates an operational vector whereby an induced failure (DoS, network partition) can allow malicious actions to proceed. Enterprises must design redundant monitors and insist on SLAs, or choose tenant-local deployment where available.
How GenAI amplifies citizen app risk — and why runtime governance matters
Generative AI and autonomous agents change two vectors simultaneously: speed and autonomy. Agents can
decide at runtime, chain tool calls, persist short‑term memory and call external data sources. That means a compromise or malicious prompt can result in rapid, programmatic exfiltration or harmful actions across multiple systems.
Finzi’s core worry — that GenAI blurs internal/external boundaries because agents often need external context and can therefore be both internal and external assets — is validated by platform design and industry analyst forecasts. Gartner predicts that autonomous agents and action models will be widely used by 2028, with one‑third of GenAI interactions invoking action models and autonomous agents. This validates the structural shift that governance and runtime controls must address. Vendors are racing to offer runtime protections for agents. Palo Alto Networks’ Prisma AIRS and other entrants explicitly position agent discovery, runtime defense, model inspection and continuous red‑teaming as the new security stack for agentic systems; they echo Finzi’s argument that prevention at runtime — not just discovery — is essential.
Supply‑chain risk in connectors and templates: the hidden dependencies
Citizen builders rarely assemble apps from scratch. They install connectors, apply templates, and reuse actions — and these components are the citizen developer supply chain. When connectors are misconfigured, outdated or over‑permissive, they act as privileged dependencies with high‑impact blast radius.
Microsoft’s Power Platform guidance frames connectors as a first‑class governance concern: DLP policies must classify and control connector groups, tenant isolation can limit cross‑tenant flows, and admins are encouraged to block or restrict connectors in the default environment until they are vetted. The guidance also recommends limiting custom connectors and controlling who can create them. Practical supply‑chain controls include:
- Vendor and template vetting: maintain an approved catalog of templates and connectors that meet internal security and privacy standards.
- Least‑privilege connectors: restrict connector actions and only allow the minimal set of operations needed by an app.
- Continuous monitoring: track connector usage, newly installed connectors, and privilege escalations across environments.
- Source provenance: require signed templates or catalog provenance where possible and treat third‑party templates like external dependencies subject to SCA (software composition analysis) and periodic review.
Treating connectors as dependencies — and adding continuous monitoring and lifecycle rules — turns a one‑time review into a managed supply‑chain process, exactly as Finzi recommends.
What security leaders should measure now
Finzi suggests three metric families: visibility, exposure, and runtime indicators. Those categories are practical and map to action. Implement these as core KPIs:
- Visibility
- Percentage of citizen‑built apps/agents discovered vs estimated total.
- Time to first inventory for new apps or agents.
- Percentage of apps mapped to an owner or sponsor.
- Exposure
- Fraction of apps with external-facing endpoints or public sharing (Finzi’s interview cites an estimate that around one‑fifth are externally facing; that number is attributed to practitioner observations and should be validated against organization‑specific telemetry rather than treated as universal fact). This particular “one‑fifth” claim appears in the interview but lacks a broadly published independent study to corroborate; treat it as directional and verify in‑tenant.
- Runtime indicators
- Percent of blocked vs allowed tool invocations after runtime policy deployment.
- Mean time to remediate misconfigurations flagged by automated scans.
- False positive / false negative rates for inline blocking decisions.
Microsoft and industry guidance recommends making inventory and control baseline activities (DLP policy coverage, tenant isolation settings, connector classification), then adding runtime metrics that show whether blocking and remediation reduce exposure over time.
Automation — the only realistic path to scale
Finzi is emphatic that automation is not optional: discovery, continuous scanning, runtime decisioning and automated remediation workflows are necessary to keep pace with thousands of citizen builders. Manual gates, ticket queues and ad hoc reviews cannot scale.
Automation should cover four linked capabilities:
- Discovery and ownership mapping — automatically inventory apps, bots, and agents and link each to an owner.
- Continuous scanning — runtime and configuration checks that find misconfigurations, secrets, injection surfaces and over‑permissioned connectors.
- Runtime decisioning — synchronous allow/block/modify verdicting for agent tool calls when the platform supports it (e.g., Copilot Studio’s webhook model).
- Guided remediation — contextual, interactive guidance that helps citizen developers fix issues quickly (automated remediation orchestration reduces help‑desk friction and accelerates fixes).
Companies already launching runtime agent security products (including the likes of Palo Alto’s Prisma AIRS and specialist LCNC security vendors) position the market around this automation stack: inventory + baseline + runtime enforcement + remediation. The architectural pattern is consistent; what varies is telemetry handling, deployment topology, and the robustness of SLAs and data residency controls.
Common misconfigurations and repeat offenders
Based on the interview and corroborating platform guidance, these patterns appear repeatedly across enterprises:
- Hard‑coded secrets and embedded tokens in canvas apps or flows.
- Overbroad sharing defaults (apps shared with “everyone in the organization”).
- Exposed internal APIs through custom connectors lacking auth controls.
- Sensitive data surfaced through naive data views or unfiltered templates.
- Use of third‑party templates without vetting or versioning controls.
Microsoft’s Power Platform guidance explicitly highlights the risks of oversharing and prescribes blocking new connectors in the default environment, tenant isolation, and restricting custom connectors to reduce these exact mistakes.
Practical roadmap: how to start securing citizen development and agents today
- Inventory first
- Run automated discovery for apps, flows and agents across Power Platform, Copilot Studio, ServiceNow, UiPath, and similar platforms.
- Map owners, connectors, and data sources to each artifact.
- Apply immediate containment
- Configure DLP policies to block risky connectors in the default environment and limit sharing scopes.
- Enforce tenant isolation and IP firewalling for Dataverse and sensitive connectors.
- Pilot runtime monitoring for high‑risk agents
- Start with agents that can write to payroll, change HR records, or exfiltrate PII.
- Run external monitors in logging (observe‑only) mode first to collect plan payloads and latency metrics before enabling blocking. Industry guidance recommends staged rollouts: log‑only → alerting → block.
- Define acceptable failure modes and SLAs
- Decide whether critical actions require fail‑closed behavior and what redundancy you need to avoid fail‑open windows.
- Require vendors to provide p95/p99 latency figures and multi‑region redundancy guarantees when they operate monitors outside your tenant.
- Automate remediation and developer engagement
- Integrate findings into CI/CD and issue trackers with remediation playbooks contextual to citizen developers.
- Provide in‑platform remediation templates that non‑technical makers can apply safely.
- Continuous red‑teaming and policy engineering
- Test monitors with adversarial prompts and model‑aware evasion techniques.
- Tune policies iteratively to balance security and productivity; expect an operational cost for policy management.
Risks, limits and what to verify before buying into a runtime monitor
- Data residency and retention promises: If a vendor claims “transient analysis only,” demand contractual proof, audits (SOC2, ISO), and technical diagrams showing in‑memory processing or tenant-hosted deployment options.
- Performance at scale: Validate p95/p99 latency under load, and test failover behavior. Confirm whether the platform defaults to allow or deny on timeout and whether you can opt for alternate fallback logic.
- Operational friction: Inline blocking can produce false positives that disrupt legitimate workflows. Ensure vendors provide staged rollout support, explainability in decisions and a manageable exception/appeal workflow.
- Supply‑chain of connectors and templates: Vendors that scan connectors and templates for known risky patterns provide useful additional hygiene, but customers should still require documentation and vetting of third‑party components.
- Model drift and evasion: Agents can be retrained or manipulated. Runtime monitors must be continuously red‑teamed and updated to detect adaptive evasion—this is operationally expensive but essential.
Where product announcements include hard numeric claims (e.g., specific SLA numbers, scale limits, latencies), procurement teams should treat those as testable requirements and insist on proof-of-concept results and reference deployments before trusting them in production.
Looking ahead: 3–5 years and how to prepare
Finzi’s forecast — an environment dominated by thousands of dynamic AI agents that fetch external data, call internal APIs and collaborate autonomously — matches major analyst predictions. Gartner projects that a substantial share of GenAI interactions will invoke action models and autonomous agents by 2028, signaling a system‑level transformation rather than a niche feature. Three pragmatic implications follow:
- Internal exposure will matter as much as external exposure. Treat agents and citizen apps as first‑class identities in your IAM model, with lifecycle rules and least‑privilege controls.
- Runtime governance will be mandatory. You will need always‑on enforcement and observability that watches what agents actually do, not only how they were configured.
- Continuous visibility will be the baseline. Quarterly inventories won’t cut it. Organizations must adopt continuous discovery and exposure management approaches for LCNC and agentic assets.
Enterprises that start now — by building inventory, applying DLP connector policies, piloting runtime monitors for high‑risk agents, and automating remediation — will be far better positioned than those that retroactively bolt controls on after an incident.
Conclusion — a defender‑first checklist
- Treat citizen apps and AI agents as first‑class assets: inventory, assign ownership, and enforce least privilege.
- Apply DLP and tenant isolation in Power Platform; restrict and vet connectors and templates before broad exposure.
- Pilot runtime enforcement in logging mode, measure latency and failover behavior, then move to staged blocking only after tuning.
- Demand proof (latency, retention, topology) from vendors and insist on tenant‑centric or VNet‑backed deployment for regulated workloads.
- Automate remediation flows and provide targeted guidance for citizen developers so fixes are fast, contextual, and low friction.
- Continuously red‑team agents and monitors to keep pace with adaptive adversaries and model drift.
Yair Finzi’s central warning — that manual detection cannot keep up and that the unmanaged internal attack surface is now the single biggest risk — is a practical call to action framed by clear technical and operational constraints. The platforms are evolving to offer inline enforcement, and vendors are racing to provide solutions, but the burden of secure adoption ultimately falls on organizations: define the metrics, verify the claims, measure the SLAs, and operationalize automation before letting agentic automation run free.
Note on specific claims flagged for verification: Finzi’s interview references that “roughly one‑fifth of no‑code apps and agents are externally facing.” That figure appears as a practitioner observation in the interview and could be a useful heuristic, but it is not tied to a publicly available, peer‑reviewed study in the sources reviewed here. Treat that particular number as directional and verify it with your in‑tenant discovery telemetry before operational decisions are made.
Source: TechNadu
Understanding Citizen Application Development Platforms, Their Security Risks, and the Rise of Gen AI