SentiQL

Note: This analysis is based entirely on the self-reported project description provided by the author. No external verification, funding history, revenue data, customer names, or traction metrics are available.

The description states that SentiQL is a "semantic firewall" for AI agents to access PostgreSQL databases. It compiles only bounded parameterized SQL and enforces access control through:

• OIDC-based workload identity verification
• Versioned policy checks against purpose, resource, fields, tenant scope, selectors, and limits
• PostgreSQL Row-Level Security (RLS) as a defense-in-depth boundary
• Local SQLite audit logging with decision records, policy hash, correlation ID, and database outcome
• Optional AST policy evaluation using @pgsql/parser that fails closed

It is built as a Node.js MCP server with typed capabilities instead of raw SQL endpoints.

Claim: SentiQL is a semantic firewall for AI-agent access to PostgreSQL.

Evidence: Author's own write-up.

Inference: It functions as an authorization layer between AI agents and databases.

Justification: The description outlines how it verifies identity, checks policies, compiles SQL, and uses RLS.

The author positions SentiQL as a solution to the problem of "giving an agent a database connection is still too much power." They emphasize that traditional methods like prompts ("only access this customer’s records") are insufficient because agents can bypass those instructions through unsafe SQL or unauthorized fields.

They describe SentiQL as enforcing boundaries via software rather than instruction, and they frame it as an alternative to exposing raw SQL to AI agents.

Claim: SentiQL is a boundary enforcement tool for AI-agent database access.

Evidence: Author's own write-up.

Inference: It aims to replace prompt-based controls with code-enforced policies.

Justification: The description contrasts its approach with "instructions" and emphasizes software enforcement.

The author does not explicitly name target customers or define an ideal customer profile (ICP). However, the context suggests that SentiQL is aimed at organizations using AI agents to interact with PostgreSQL databases, particularly those concerned about data security and access control.

It seems designed for developers or platform teams who want to govern how AI tools can query or mutate their data.

Claim: The target audience includes developers or platform teams managing AI agent access to PostgreSQL.

Evidence: Author's own write-up.

Inference: Likely used by enterprises with AI agents and PostgreSQL systems.

Justification: The focus on RLS, OIDC, and policy enforcement implies enterprise-level use cases.

There is no evidence of pricing or business model in the description. The author does not mention monetization strategies, licensing models, or any commercial arrangements.

Claim: No information provided about business model or pricing.

Evidence: Author's own write-up.

Inference: Likely a SaaS or on-premises tool for enterprise customers.

Justification: Based on the technical complexity and use case (enterprise data access), but not stated.

SentiQL is built using:

• Node.js
• MCP (Model Control Protocol) server architecture
• Docker (mentioned in tech stack)
• JavaScript, OIDC, JWKS, RLS, Zod, AST parsing (@pgsql/parser)
• Express dashboard for audit console
• Local SQLite logging
• Policy bundles defined in JSON

It implements:

• Typed capabilities instead of general SQL endpoints
• Versioned policy enforcement
• Fail-closed behavior for unsafe inputs or parser errors
• Shadow observation via AST review
• Differential test harness across PostgreSQL versions 13–18
• 287 automated tests passing

Claim: SentiQL is a Node.js MCP server with typed capabilities and policy-driven SQL compilation.

Evidence: Author's own write-up.

Inference: It supports enterprise-grade security through multiple layers of control.

Justification: Use of OIDC, RLS, AST policies, and audit logging suggests robustness.

There is no evidence of traction or maturity beyond the hackathon submission. The project is described as a demo with no external dependencies, and there are no mentions of:

• Customers
• Revenue
• Product usage
• Deployment in production environments
• Partnerships
• Funding rounds

Claim: No evidence of traction or commercial adoption.

Evidence: Author's own write-up.

Inference: Likely a prototype or proof-of-concept.

Justification: The project is described as an offline demo and submitted to a hackathon.

The author does not reference competitors. However, the concept aligns with:

• Database access control tools
• Semantic authorization systems for AI agents
• Row-Level Security (RLS) implementations in PostgreSQL
• MCP-based tooling for AI agent orchestration

It appears to address a gap in secure AI-agent-to-database interaction, especially where traditional SQL access is too permissive.

Claim: No direct competitor references.

Evidence: Author's own write-up.

Inference: Likely addresses a niche in secure AI-agent database access.

Justification: The combination of MCP, RLS, and semantic authorization suggests a unique approach.

• No production use or pilot data: The project is described as a demo with no real-world deployment.
• Unverified claims: All features are self-reported without independent validation.
• Limited team size: Only one member listed, which may limit development velocity or scalability.
• Hackathon origin: Submitted to a hackathon; not necessarily indicative of long-term viability.
• Offline-only demo: The demo does not require external infrastructure, suggesting it's not yet production-ready.

Claim: No evidence of real-world deployment or adoption.

Evidence: Author's own write-up.

Inference: Risk of being a prototype with no commercial traction.

Justification: The project is described as a hackathon submission and offline demo.

1. Has SentiQL been tested in any real-world environments or pilot programs?
2. What are the performance implications of enforcing policy at every query?
3. How does SentiQL handle schema drift or changes to PostgreSQL configurations?
4. Are there plans for integration with specific AI agent platforms (e.g., OpenAI, LangChain)?
5. What is the roadmap for moving from a demo to production-ready tooling?
6. How are audit logs managed and secured in production?
7. What level of support or SLA does SentiQL offer?