Secure Federated Queries by Treating AI Agents as Service Accounts

In this interview with Help Net Security, Paras Malhotra, CISO at Starburst, outlines the company’s strategy for managing data governance across federated query environments. Key topics include layering Starburst’s access controls above native source permissions, tiering vendor risk across more than 200 partners and connectors, and building robust audit trails for autonomous agents. The discussion also covers how AIDA converts natural language into SQL while defending 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.

When querying data where it lives, the engine inherits the access models of every source it touches: native database grants, S3 policies, and warehouse roles. Reconciling Starburst’s RBAC and ABAC with underlying systems without creating permission gaps is a core challenge. Malhotra explains that Starburst uses built-in access control as an additive enforcement layer above source systems. Every query passes through a single policy evaluation before reaching the source. Source-level permissions remain enforced by the source, but Starburst adds restrictions on top. A query that passes their access control can still be denied by the source, while a query that fails never reaches the source at all.

The governance program tracks vendor risk across more than 200 partners and connectors, each representing a piece of code reaching into a customer system. To avoid unmanaged dependency sprawl, Starburst tiers vendors. Those processing customer data or with significant integration depth undergo a full review: SOC 2 Type II, penetration tests, DPA review, and subprocessor chain review. Lower-risk vendors receive a lightweight assessment, questionnaire, and annual recertification. Connector security reviews focus on scanning connector code, remediating vulnerabilities, secure credential handling, configuring appropriate access controls, and ensuring data in transit is encrypted.

When an autonomous agent runs an improper query, attribution can be murky: was it the agent, the model vendor, the prompt author, or the system that granted the token? Malhotra acknowledges this as one of the hard problems in AI security, not yet fully solved by the industry. Starburst records at multiple layers to ensure a forensic trail survives ambiguity. At the query engine layer, every AIDA-generated query is logged with context: the natural language prompt, the generated SQL, user identity, data product scope, and execution result. This trail is owned entirely by Starburst, separate from what the model vendor logs. Even if a bad query’s origin is unclear, they can show exactly what was run, against what data, and by whom.

AIDA lets a business user ask a question in natural language and generates a query. With a language model between a person and the policy engine, prompt injection becomes a path toward data exfiltration. Malhotra explains that prompt injection is their most actively managed AI attack surface. The threat model is specific: a user crafts a request to make the model generate SQL that bypasses policy intent. Starburst relies on several controls. Most importantly, AIDA’s access control is enforced at the query engine layer. No matter what the model generates, the resulting SQL runs through built-in access control. If the query references a table or data product the user lacks privileges for, it fails at execution. The LLM cannot grant permissions; it only generates SQL that the policy engine validates. The model is not the authorization layer.

Second, AIDA only shows the model data the user is already allowed to see. Sessions are restricted to a specific data product, reducing the injection surface because the model’s context is constrained. Third, Starburst is implementing input and output guardrails, including prompt injection detection, topic restriction, and output filtering, as pre and post layers around every model call. No single control is sufficient; defense in depth is key.

Starburst exposes 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. Malhotra notes that the security industry is still working out the right answer for identity, authorization, and rate-of-abuse detection for agents. On identity, every MCP client is treated 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. The MCP server enforces that scope at the query layer, with 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 constrains what an agent can reach. An agent accessing data through MCP can only access what it’s been explicitly granted at the data product level. It cannot enumerate schemas or discover unauthorized data. The semantic layer limits the blast radius if an agent is compromised or misbehaves. On rate-of-abuse detection, the agent loop itself is constrained. AIDA is capped at 25 iterations per session, preventing indefinite chaining. Starburst is still building out the monitoring story for non-human callers and working with 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, but an agent doing the same might be normal. The principle is that agents should start with the minimum access needed for their specific task, not broad access granted for convenience. Every token issued to an agent should have an expiry and a documented owner accountable for its behavior, making machine identity governable at scale.