Launching today
SecuriX
Trust Layer for Autonomous AI
10 followers
Trust Layer for Autonomous AI
10 followers
The Agent Access Security Broker (AASB). Connect Claude, ChatGPT, and custom AI agents/Chatbots to Jira, Slack, and Notion, GMail, Zoho Mail without leaking tokens or losing IT control.
@subramanyan_balakrishnan the "Consume AI Responsibly" framing and the pivot story both land. and the trio of granular permissions/audit trail/kill switch is the right operational shape for this kind of product.
drilling into "granular permissions" though - there are very different kinds of granular, and they have very different security properties (especially against prompt-injection class attacks):
scope-at-grant-time (OAuth-style: this token can hit endpoints X, Y, Z)
per-call-at-runtime (each tool call inspected against a policy)
per-context (same token, different powers depending on which agent / which user / which thread is asking)
where does securix sit on this gradient by default - and is the user expected to write the policy themselves, or do you ship sensible per-provider defaults out of the box?
@arturbrugeman Thanks so much—really glad the framing resonated, and this is exactly the right question to be asking. You hit the nail on the head regarding the threat model: prompt injection makes broad, grant-time scopes way too risky for autonomous agents.
To answer your question, SecuriX sits firmly in the per-call-at-runtime category, but we actually tackle the vulnerability at three distinct stages: connection, request, and response.
Here is how our current architecture handles it:
1. JIT (Just-In-Time) / Self-Healing Auth We mitigate the "scope-at-grant-time" risk before a call is even made. When a user initially connects a provider, we don't ask for a massive, terrifying list of scopes upfront. Instead, we only request a specific scope exactly when an agent attempts to use a tool that requires it. This keeps the initial access footprint as small as mathematically possible.
2. The Execution Pipeline We provide Secure MCP URLs that users plug directly into their AI agent or chatbot. Instead of the agent interacting with the provider directly, it sends all tool calls to us, and we execute the exact APIs on behalf of the agent.
To secure this pipeline, we run a dedicated OPA (Open Policy Agent) service right at our API Gateway layer, applying deterministic Rego policies at two distinct stages:
Pre-call (Request level): We inspect and filter the tool call payload before it is ever executed against the provider.
Post-call (Response level): We inspect and filter the returned data before handing it back to the AI model, minimizing data exfiltration risks.
As for the policies themselves, we are taking a hybrid approach:
Out of the Box: We ship with sensible defaults per provider (like enforcing strict "Draft-Only" actions for communication tools) so users don't have to start from scratch.
Custom Policy-as-Code (In Development): Because the entire infrastructure relies on deterministic Rego scripts, the architecture is fully equipped to handle custom, granular policies for highly specific user or context-dependent use cases.
Appreciate you drilling into the architecture! Let me know if you want to dig deeper into how we are handling the request/response filtering or the JIT auth flow.