Insider-Risk Management with DVSA (https://github.com/ravibeta/dvsa-api) platform: 

Insider risk concerns model behavior and outputs that could significantly affect the analytics stack DVSA provides for drone AI applications, as described in the eponymous article. This document applies that article’s recommended trust architecture to our system. 

Models act like powerful insiders: they have access, intent, and the ability to act. DVSA relies on them for tasks ranging from geospatial pipelines to feedback control loops in critical mission systems. Our earlier work proposed two safeguards. The first is a health signal that measures semantic drift as the cosine distance between rolling embedding centroids. The second is a tiered architecture in which Qdrant global search and LLM agent reasoning run in the cloud. We now extend our scope beyond the data and infrastructure to the models themselves: how they act, which tools they can call, and how they might be manipulated or abused. 

In DVSA, every model, agent, and tool is an insider whose capabilities could leak information, misroute queries, amplify bias, or be steered by hostile input. We test the agent layer against prompt-injection attacks that hide directives in video metadata, and we mitigate them with SQL schema allowlists and input sanitization. We also protect data with AES-256-GCM encryption and differential privacy. Three principles govern every potential insider action: least privilege, strong provenance, and continuous monitoring. 

Least privilege begins with tools. The agentic retrieval layer exposes eight specialized functions, from semantic frame search to heatmap generation, and each should be tightly scoped. An agent answering a parking-lot query, for instance, should search only the relevant account, mission, and time window rather than the entire corpus. In Azure AI Search, we add accountid and video-id as filterable fields and pass OData filters such as odata_filter = "accountid eq '008333'". As a result, queries reach only the vectors derived from the user’s own uploaded videos, even though the index is shared across users. These filters are mandatory. Every agent tool call must carry tenant and mission context, which the API enforces and a policy engine such as Open Policy Agent validates. A model should never see more data than the current question requires. 

Provenance and lineage form the second pillar. We already attach provenance atomically at ingest and maintain full lineage graphs that trace every transformation from raw frame to archived artifact. These graphs support compliance audits, targeted reprocessing after model upgrades, and complete erasure cascades. We can extend this lineage to model decisions. Azure already produces a trace for every agent run, recording the tools called, frames retrieved, filters applied, model versions used, and the content of the final answer. These traces become our insider-activity logs. We can mine them for anomalies, such as an agent suddenly querying beyond its usual geospatial bounds or calling tools in a sequence that resembles reconnaissance rather than analysis. We then feed them into the same observability stack that monitors ingestion, localization, and drift. The result is a new signal, “model behavior drift,” which measures how far today’s tool-calling patterns deviate from a baseline of legitimate use. 

Exfiltration and misuse map cleanly onto DVSA’s multi-tenant, high-value corpus, because aerial urban video is sensitive by default. Our GDPR section already addresses this through four measures: purpose limitation enforced at flight-plan registration, importance sampling for data minimization, cascading deletion across the provenance database, S3, and Qdrant vectors, and latitude-longitude-time frame search for data subject access requests. We can add exfiltration guards at the agent layer. These would detect queries that resemble bulk export, such as “give me all frames with cars in Redmond between 2023 and 2025,” cap result sizes and aggregation granularity, and require elevated approval or out-of-band justification for queries that exceed those caps. We must scan not only prompts and their metadata but also the model behavior that attempts to fulfill them. 

Model supply chain and configuration drift are another dimension. DVSA requires embeddings to carry model-version metadata and orthophotos to be refreshed quarterly, and we trigger re-embedding when measured drift crosses a threshold. Building on this, we can treat model binaries, configuration files, and tool registries as high-risk artifacts. Any change to CLIP, YOLO, Qdrant index parameters, or agent tool definitions should pass through signed, auditable change control. Our dvsa_ Prometheus namespace can expose configuration hashes and model-version distributions and raise an alert when an unexpected version reaches production. This is how we catch a compromised model or misconfigured tool before it behaves like a malicious insider. 

Segmentation and isolation ensure that no single insider sees everything. DVSA’s tiered edge-versus-cloud architecture already provides a degree of segmentation, with Qdrant global search and LLM agent reasoning confined to the cloud. We can strengthen it in two ways: edge agents see only their own mission’s embeddings and metadata, and cloud agents operate in per-tenant namespaces with strict cross-tenant barriers. For cross-mission analytics, we can introduce specialized “auditor” agents with narrower tools and stronger logging instead of letting general-purpose agents roam the corpus. In effect, we assign our models roles, such as mission analyst, fleet auditor, and compliance checker, and give each role its own toolset and data scope. 

Finally, observability should cover activities as well as metrics. Alongside existing metrics such as agent task-completion rate and cost per query, we can add agent intent classification and tool-use entropy. A lightweight classifier could label each agent run as normal analysis, exploratory browsing, or suspicious bulk access based on its tool sequence, filter breadth, and result size. Tracking tool-use entropy per agent would reveal sudden spikes in unusual tools or filters that may indicate insider-like exploration. 

Taken together, these measures meet the expectations for insider-risk management: treating models, agents, and tools as insiders; atomic provenance; semantic drift monitoring; tiered edge and cloud deployment; access control lists; encryption; differential privacy; and a rich observability stack. 

 

Reference:  Insider risk eponymous article: https://snscratchpad.com/posts/models-as-insider-risks/