Show HN: Did Supabase MCP leak your database?

Tansive lets you securely run AI agents and tools with fine-grained policies, runtime enforcement, and tamper-evident audit logs — so you can trust what they’re doing, without locking you into any specific framework, language, or cloud.

Understand and control:

• what AI agents can access
• which tools they can call
• the actions they perform
• who triggered them

All with full execution graph visibility and tamper-evident audit logs.

Developers can embed agent workflows into existing apps or build new solutions on top of their data — in their current programming language, without learning complex SDKs or specialized frameworks.

Ops teams can run agents just like they run APIs and services today — declaratively, securely, and with full observability and compliance.

Tansive is in early alpha (0.1.0) — not production-ready, but functional enough to explore in real workflows.

We’re gathering feedback from teams who care about integrating AI agents safely and governing them with clear policies and auditability. If these challenges matter to you, your ideas can help shape where Tansive goes next. We invite you to check out the demos, documentation, and try Tansive out.

• 💡 Why Tansive?
• ✨ Key Features
• 🎬 See it in Action
• 📋 What Works, What's Coming, and What to Expect
• 🚀 Getting Started
  • Architecture Diagram
  • Install Tansive
  • Setup a Catalog
  • Run the Example Agents
• 📄 Documentation
• 💬 Community and Support
• 💼 License
• 🙏 Contributing
• ❓ FAQs and Project Background
• 🛠️ Dependencies
• 🛡️ Security Notice

Companies and Teams want to adopt AI agents, but face real obstacles:

• Context:
  Agents need context from many systems, but integrating securely across APIs and data silos is hard and often requires costly new data pipelines.

• AI agents are non-deterministic actors:
  Hard to observe and break traditional DevOps models. Current Authn models are designed for systems that behave deterministically, not for Agents. Prompt engineering and using one AI model as a guardrail for another are necessary, but not sufficient.

• Chained Actions amplify risk:
  When agents and tools call each other, small problems have a large blast radius.

• Production Gaps:
  Existing frameworks help build agents but don’t adequately address safe deployment, policy enforcement, or auditability.

• Operational Overhead:
  Introducing new APIs and services that speak Agent protocols increases complexity, security surface area, and compliance burden.

Tansive helps teams take agents to production safely — enforcing scoped policies, providing tamper-evident audit logs, and integrating without reinventing your stack.

• Declarative Agent Catalog
  A hierarchically structured repository of agents, tools, and contextual data, partitioned across environments like dev, stage, and prod, and segmented by namespaces for teams or components.

• Runtime Policy Enforcement
  Enforce fine-grained controls over access, execution, and data flows. Every invocation is checked against policy in real time.

• Immutable Constraints and Transforms
  Pin runtime sessions to specific values and apply user-defined transforms to modify or redact inputs to agents and tools. Protect sensitive data (e.g. PII, Health data), apply runtime feature flags, and adapt or enrich inputs to match the expectations of your current systems without undertaking costly data migration initiatives

• Tamper-Evident Audit Logging
  Maintain, hash-linked, signed logs of every action for observability, compliance, and forensic analysis.

• Language and Framework Agnostic
  Author tools and agents in any language — Python, Bash, Go, Node.js — with no mandatory SDKs.

• GitOps Friendly
  Configure everything via declarative YAML specs version-controlled in Git, modeled on familiar cloud-native patterns.

Below are examples showing how Tansive enforces policies and protects sensitive data:

What you'll see

• ✅ Allowing an agent to restart a deployment in dev
• 🚫 Blocking the same action in prod
• 🔒 Restricting a health bot to one patient’s records

📺 Demo Video: Watch the guided walkthrough (🕒 8:57)

Demonstrates: Policy enforcement at runtime based on environment
Scenario: AI agent debugging an e-commerce system
Key Point: Same action allowed in dev, blocked in prod

Dev Environment

In this interactive agent session, the k8s_troubleshooter used the list_pods tool to obtain the status of running pods, determined that the orders-api pod was is a CrashLoopBackOff state, and used the restart_deployment tool in an attempt to fix the problem.

Now we will do the same but switch the session to production view. We will only change the view name in the --view option.

Prod Environment

When we switched the view to production, Tansive blocked the invocation of the restart_deployment tool based on the policy bound to the prod-view.

Demonstrates: Data access control through session pinning
Scenario: Health bot answering patient questions
Key Point: Session locked to specific patient, blocks access to other records

Access John's records but not Sheila's:

We locked the session to John's patient_id via Session Variables during Session creation. And we asked the agent to retrieve both John and Sheila's bloodwork. John's was approved but the request for Sheila's bloodwork was denied.

Tansive is in early alpha, which means core functionality is working but there's still plenty to build. Here's what you can expect:

What you can do today:

You can do the following in non-production environments:

✅ Deploy agents for real workflows such as analyzing support tickets, restart failed services in dev environment, or validate data before orders are processed
✅ Enforce policies like "This agent can only access customer data for tier 1 support cases"
✅ Use session pinning to enforce data access controls like "This session can only access prospect data for the current lead"
✅ Write tools in Python, Node.js, Bash or any compiled language (binary invocation)
✅ Deploy your agent catalog and apply policies declaratively
✅ Single User only

What's coming:

• Multi-User mode with project support
• Support for external Resources such as secret stores, vector DBs, conversational memory, cache
• Prometheus endpoint for observability
• Performance optimizations
• Additional security features
• Better documentation and examples

Alpha expectations:

• ✅ Core functionality works and is tested
• ⚠️ API may change between releases
• ⚠️ Some rough edges in the UX
• ❌ Not yet production-ready for critical systems

Perfect for:

• Teams experimenting with AI agents
• Proof-of-concept deployments
• Early feedback and feature requests
• Non-critical workflows

Read the full Installation and Getting Started guide at docs.tansive.io

Note: Tansive is currently in 0.1-alpha and rapidly evolving. Expect rough edges — your feedback is welcome!

This diagram is to set the context for the docker all-in-one quickstart image we'll use in this section. To learn about the architecture of Tansive, visit: Concepts and Architecture

Below is a high-level view of how Tansive components connect.

The Tansive Server acts as the control plane, coordinating policies, sessions, and audit logs. Tangent is the execution runtime that runs tools and agents. One or more Tangents can be registered with the server, and workloads are dispatched based on availability and capabilities. The CLI connects to the server for management and orchestration.

1. Run the Tansive Server and Tangent

Wait for the tangent service to reach the started state. Use --pull always option if you have already run Tansive and need to get the latest images.

2. Install the CLI

Download the appropriate release binary named tansive-<version>-<os>-<arch>.tar.gz from Releases or build from source.

1. Configure API Keys

Configure API Keys to run the sample agents.

Create a .env file in the project root with your OpenAI or Anthropic API Key. Replace only the API key you want to use - keep the placeholder for keys you don't need (e.g., if you only use Claude, keep <your-openai-key-here> as-is).

2. Setup the example Catalog via declarative scripts

Quick smoke test: Run tansive tree to verify the Catalog was set up correctly.

Run the agents shown in the "See it in Action" section.

Run the Kubernetes Troubleshooter Agent (Control agent actions via scoped Policy)

You don't need a cluster. The tools sends mock data.

Change model to "gpt4o" or "claude" depending on the API Key

Run the Health Bot Agent (Protect sensitive PHI data via session pinning)

Get started with the docs or start a discussion.

Documentation and examples are available at https://docs.tansive.io

Questions, Feedback, Ideas?

👉 Start a discussion

Follow us: X | LinkedIn

🌐 Learn more at tansive.com

Tansive is Open Source under the Apache 2.0 License

Contributions, issues, and feature requests are welcome. Please see CONTRIBUTING.md for guidelines.

Built with care by a solo founder passionate about infrastructure, AI, and developer experience.

Agents can do many different types of useful things for different people, teams, companies. While I've made opinionated choices on architecture, I purposely built Tansive to be easily extensible. Trust and extensibility don't work behind closed doors. My goal, if Tansive proves it deserves it, is for an ecosystem to evolve and flourish around it. There are enough layers and adjacencies that Tansive and other ecosystem participants can monetize without impacting the functionality, utility, and viability of the open ecosystem.

Tansive is in early Alpha, and it's not ready for production use. But the foundations - hierarchical organization of agent and tool assets, policy-based views, dynamic runtime control via transforms, language agnostic runtime framework, tamper-evident logs, and extensible Resources and SkillSet abstractions - are designed to enable and sustain wide adoption of agents to automate day to day tasks without compromising on safety and compliance.

I hope you will try Tansive in your non-production environments with real workloads and provide feedback on the problems you face and the capabilities you’d like Tansive to deliver. Your insights will help shape a platform that aspires to become the standard for secure, auditable, agent-driven workflows. Thank you in advance for being part of this journey.

Tansive was developed privately by a single author @anand-tan, and then moved to this repository to provide a clean starting point for open-source development. The repositories are publicly archived for historical reference.

Tansive is currently founder-funded. The focus right now is on proving the usefulness of the platform and building a credible foundation.

Tansive builds on widely adopted, well-tested open-source components, including:

• Go standard library
• PostgreSQL (for catalog storage)
• Common libraries for YAML parsing, HTTP handling, and CLI UX
• No custom cryptography

Additional dependencies are listed in go.mod

📄 Concepts and Architecture

Tansive is in early alpha. While built on established components, it has not undergone third-party security audits. Use with caution in sensitive or production environments.

Read more: Security notes for 0.1.0-alpha release