Treating AI agents like service accounts for federated query security
In this interview with Help Net Security, Paras Malhotra, CISO at Starburst, explains how the company handles data governance across federated query environments. Topics include layering Starburst’s access controls above native source permissions, tiering vendor risk across more than 200 partners and connectors, and building audit trails for autonomous agents.
The conversation covers how AIDA turns natural language into SQL while guarding against prompt injection, and how the company treats AI agents querying through MCP endpoints as scoped service accounts with short-lived credentials and accountable owners.
Querying data where it lives means the engine inherits the access models of every source it touches: native database grants, S3 policies, warehouse roles. How do you reconcile Starburst’s RBAC and ABAC with the underlying systems without creating gaps where a permission looks enforced at one layer but is open at another?
This is the core tension in any federated query engine and something we think about constantly. Starburst sits on top of dozens of data sources, S3, Snowflake, Delta Lake, relational databases, each with their own native access model. A user might be blocked at the Starburst layer but find a path through a source system’s own credentials if you’re not careful about how you set things up.
Our approach is to use the built-in access control as an additive enforcement layer that sits above the source systems. It operates at the query engine layer, which means every query, regardless of which underlying system it touches, passes through a single policy evaluation before it ever reaches the source. The source-level permissions are still enforced by the source itself, but our access control adds restrictions on top of them. A query that passes our access control can still be denied by the source. A query that fails never reaches the source at all.
Your governance program tracks vendor risk across 200-plus partners and connectors. Each connector is a piece of code reaching into a customer system. How do you assess and monitor that long tail without it becoming an unmanaged dependency sprawl?
We had to be honest early on that you can’t treat 200 vendors with the same level of scrutiny. The first thing we did was tier them. Vendors that process customer data or have significant integration depth get a full review: SOC 2 Type II, penetration test results, DPA review, subprocessor chain review. The long tail of lower-risk vendors gets a lightweight assessment, a questionnaire, and annual recertification.
For connectors specifically, the risk is different from a traditional SaaS vendor review. A connector isn’t just a third-party service you’re trusting, it’s code that executes inside the query path and can touch data across multiple source systems simultaneously. Our connector security reviews focus on scanning connector code and remediating vulnerabilities identified, secure credential handling, configuring the connector for appropriate access controls, and making sure data in transit is encrypted.
When an autonomous agent runs a query that turns out to be improper, attribution gets murky: was it the agent, the model vendor, the prompt author, or the system that granted the token? How are you building an audit trail that survives that ambiguity?
This is one of the hard problems in AI security right now and I don’t think the industry has fully solved it. Our approach is to record at multiple layers so that even when attribution is ambiguous, the forensic trail is not.
At the query engine layer, every query AIDA generates is logged with context: the natural language prompt that triggered it, the generated SQL, the user identity, the data product scope, and the execution result. That’s separate from what the model vendor logs. We own that trail entirely. Even when we can’t prove whether a bad query came from a malicious prompt or a model reasoning error, we can show exactly what was run, against what data, and by whom.
AIDA lets a business user ask a question in natural language and turns it into a query. Once a language model sits between a person and your policy engine, prompt injection becomes a path toward data exfiltration. What stops a cleverly worded request from generating a query that policy would otherwise refuse?
Prompt injection is our most actively managed AI attack surface right now. The threat model is specific: a user crafts a natural language request designed to make the model generate SQL that bypasses the intent of the policy, not necessarily the enforcement, but the boundaries the policy is meant to represent.
A few things we rely on. The most important one: AIDA’s access control is enforced at the query engine layer. No matter what the model generates, the resulting SQL still runs through built-in access control. If the generated query references a table or data product the user doesn’t have privileges to, it fails at execution. The LLM cannot grant permissions. It can only generate SQL that the policy engine will then validate. The model is not the authorization layer, and keeping it that way is a deliberate architectural decision.
Second, AIDA only shows the model the data the user is already allowed to see. There’s no browsing the full catalog, each session is restricted to a specific data product. This reduces the injection surface because the model’s context is constrained to what it’s been given access to.
Third, we’re actively implementing input and output guardrails. These include prompt injection detection, topic restriction, and output filtering running as a pre and post layer around every model call. No single control is sufficient here. Defense in depth, enforce at the query layer, scope the context, add guardrails around the model, is how we manage the risk in practice.
You expose an MCP endpoint so external agents can query governed data. A non-human caller has no manager, no badge, and can act thousands of times a minute. How do you do identity, authorization, and rate-of-abuse detection for an agent the way you would for a human analyst?
This is the question I think the security industry is still working out the right answer to, and it’s one I spend a lot of time on. Machine identities interacting with data at scale don’t fit the traditional human-centric access model cleanly.
On identity, we treat every MCP client as a service account with an explicit, documented purpose. Credentials are short-lived where possible, scoped to specific data products rather than broad catalog access, and the MCP server enforces that scope at the query layer the same way it would for a human user. There’s no agent bypass. The same built-in access control policy evaluation applies regardless of whether the caller is a person or a pipeline.
On authorization, the data product model helps here. An agent accessing data through MCP can only reach what it’s been explicitly granted access to at the data product level. It can’t enumerate schemas or discover data it wasn’t given access to. The semantic layer constrains the blast radius if an agent is compromised or misbehaves.
On rate-of-abuse detection, we constrain the agent loop itself. AIDA is capped at 25 iterations per session, so the agent can’t chain indefinitely regardless of what it’s asked to do. Beyond that, we’re still building out the monitoring story for non-human callers and are working with our customers to understand their security and compliance needs.The signals are genuinely different from human behavior. A human analyst running a thousand queries a minute is an anomaly. An agent doing the same might be completely normal depending on what it’s doing.
The principle I hold to is that agents should start with the minimum access needed for the specific task they’re designed to do, not broad access granted for convenience. Every token issued to an agent should have an expiry and a documented owner who is accountable for its behavior. That accountability chain is what makes machine identity governable at scale.
Download: The IT and security field guide to AI adoption