Skip to main content

Tansive Overview

Platform for Secure and Policy-driven AI Agents​

Tansive lets you securely run AI agents and tools with fine-grained policies, runtime enforcement, and tamper-evident audit logs.

Understand and control:

  • What AI agents access
  • Which tools they can call
  • The actions they perform
  • Who triggered them

All with full execution graph visibility and audit logs.

Tansive lets developers run AI agents with controlled access to tools — you define what tools each agent can use, specify runtime validation of tool inputs, and Tansive enforces those rules while logging full tool call traces.

$ tansive session create /skillsets/tools/deployment-tools --view devops-engineer
Session created. MCP endpoint:
https://127.0.0.1:8627/session/mcp
Access token: tn_7c2e4e0162df66d929666703dc67a87a

For Ops Teams, Tansive provides a yaml based control plane for running AI agents and tools with policy-driven security and full observability.

#This example specifies Allow/Deny rules for a Kubernetes troubleshooter agent
spec:
  rules:
    - intent: Allow
      actions:
        - system.skillset.use
        - kubernetes.pods.list
        - kubernetes.troubleshoot
      targets:
        - res://skillsets/agents/kubernetes-agent
    - intent: Deny
      actions:
        - kubernetes.deployments.restart
      targets:
        - res://skillsets/agents/kubernetes-agent

💡 Why Tansive?​

  • Secure Integration: AI Tools and Agents need context from many systems, but integrating securely across different APIs is challenging. Tansive provides rules-based access control at every interface in the Agent pipeline.

  • Reduce Operational Burden: Deploy and manage AI Agents using the same GitOps processes teams use today. Tansive is cloud-agnostic and works across clouds.

  • Chained Actions amplify risk: When agents and tools call each other, small problems have a large blast radius. Tansive provides audit logs that capture the full tool call graph and policy decisions to help trace and mitigate risks.

  • Defend against Security Vulnerabilities: AI tools introduce new attack vectors like prompt injections. Tansive provides the tools to implement defense-in-depth security processes to keep systems safe.

  • Meet Compliance Requirements: Systems often have regulatory requirements to meet (SOC2, HIPAA, PCI, Data Privacy). Tansive provides policy-based control and tamper-evident logs for compliance and audits.

✨ Key Features​

  • 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 tool calls. Every invocation is checked against policy in real time.

  • Runtime 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.

  • Agents in any framework
    Author agents in any framework - LangGraph, CrewAI, Semantic Kernel, etc.

  • Tools in any language
    Author tools in any language or import tools from local or external MCP servers. Tansive will run or proxy them and create a policy-governed MCP endpoint with secure HTTP transport.

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

🔑 Key Concepts​

Before diving into how Tansive works, here are the core concepts you'll encounter:

  • SkillSet: A collection of tools and agents that work together to accomplish a specific type of task. Think of it as a template that defines what tools are available and how they should be run.
  • View: A policy that controls what actions are allowed in a session. Views define which capabilities (like kubernetes.deployments.restart or patient.labresults.get) are permitted.
  • Session: A runtime instance of a SkillSet with specific constraints applied. When you create a session, Tansive instantiates the SkillSet and applies the View policy to control access.
  • MCP (Model Context Protocol): A standard protocol for AI tools to communicate with language models. Tansive creates secure MCP endpoints that expose your tools as defined by policy and applies runtime input validation and constraints.
  • Skill: Individual tools or agents within a SkillSet. Skills can be written in any language or framework and are the building blocks of your workflows.
  • Capability: Granular permissions expressed as tags (e.g., query.sql.select, payments.reconcile) that define what actions are allowed.

🔧 How Tansive works​

For Developers:​

Tansive lets developers run AI agents with controlled access to tools — you define what tools each agent can use, and Tansive enforces those rules while logging full tool call traces.

  • Call tools via Tansive from your agents written in LangGraph, CrewAI or any of your favorite frameworks, so you get filtered tool access, runtime evaluation of tool inputs, and detailed audit logs with full tool call lineage.

  • Tansive is also an orchestrator, running your tools or agent code directly.

    • Let Tansive run your tools written in Python, Node, Go, etc. Tansive will automatically create an MCP endpoint for your tools with authenticated HTTP transport, so you don't have to manage tokens and authorization.
    • You can also have Tansive run your agent code directly. When you do, the agent will be subject to the same policy and runtime access constraints, giving you end-to-end control over the agent.

  • Run multiple concurrent sessions with different policies — Create a template with a collection tools and agents tagged with Capability tags, then create filters based on those tags to control what each session can do. In Tansive, a collection of tools and agents that can together accomplish a type of job is called a SkillSet. Policies are called Views.

Examples: Create tool and agent sessions

e.g., You can create secure MCP endpoints for different roles to configure tools such as cursor.

$ tansive session create /skillsets/tools/deployment-tools --view devops-engineer
Session created. MCP endpoint:
https://127.0.0.1:8627/session/mcp
Access token: tn_7c2e4e0162df66d929666703dc67a87a

e.g., You can run a complete agent workflow with a prompt. You can also restrict the agent from accessing sensitive data.

$ tansive session create /skillsets/agents/health-record-agent \
--view prod-view \
--input-args '{"prompt":"John Doe and Sheila Smith were looking sick. Can you please check their
bloodwork and tell me if there is anything wrong?","model":"claude"}' \
--session-vars '{"patient_id":"H12345"}' --interactive

# This agent session runs the agent bot with the provided prompt. We scoped the session to John's patient_id
# so while the agent can access John's data, it cannot access Sheila's.

For DevOps Engineers:​

Tansive provides a yaml based control plane for running AI agents and tools with policy-driven security and observability.

  • Create a Catalog of workflows consisting of Tools and Agents by defining them in YAML
  • Assign them across different environments such as dev, stage, prod. Give teams their own namespace in each environment
  • Define access and runtime policies in YAML based on environments and namespaces
  • Run workflows scoped to the policies you created.
  • Run your tools and agents across different VPCs depending on systems they need to access.
  • Deploy and manage AI Agents using your existing CI/CD processes.
Example yaml definition of a SkillSet
spec:
  version: "0.1.0"
  sources:
    - name: resolve-patient-id
      runner: "system.stdiorunner"
      config:
        version: "0.1.0-alpha.1"
        runtime: "node"
        script: "resolve-patient-id.js"
        security:
          type: default
    - name: patient-bloodwork
      runner: "system.stdiorunner"
      config:
        version: "0.1.0-alpha.1"
        runtime: "python"
        script: "patient_bloodwork.py"
        security:
          type: default
    - name: agent-script
      runner: "system.stdiorunner"
      config:
        version: "0.1.0-alpha.1"
        runtime: "python"
        script: "run-llm.py"
        security:
          type: default
  context:
    - name: claude
      schema:
        type: object
        properties:
          apiKey:
            type: string
          model:
            type: string
        required:
          - apiKey
          - model
      value:
        apiKey: { { .ENV.CLAUDE_API_KEY } }
        model: claude-3-7-sonnet-latest
    - name: gpt4o
      schema:
        type: object
        properties:
          apiKey:
            type: string
          model:
            type: string
        required:
          - apiKey
          - model
      value:
        apiKey: { { .ENV.OPENAI_API_KEY } }
        model: gpt-4o
  skills:
    - name: resolve-patient-id
      source: resolve-patient-id
      description: "Resolve patient ID"
      inputSchema:
        type: object
        properties:
          name:
            type: string
            description: "Patient name"
        required:
          - name
      outputSchema:
        type: string
        description: "Patient ID"
      exportedActions:
        - patient.id.resolve
      annotations:
        llm:description: |
          Resolve the patient ID from the patient's name.
          This skill is used to resolve the patient ID from the patient's name.
          It requires the patient name as input and will return the patient ID in json.

🧱 Architecture​

Functional Architecture of a Tansive Session​

This diagram shows how Tansive orchestrates tools, policies, and agents within a session runtime

Tansive Functional Architecture

When you create a session, Tansive creates a runtime instance of the "SkillSet" constrained by the specified "View". SkillSet is a yaml template that specifies all the tools and agents involved in accomplishing a specific type of task (e.g., placing an order based on availability of inventory) along with information on how to run them, and what capabilities they expose.
A "View" is a policy that specifies what capabilities are permitted to be used in a session. Capabilities are expressed via tags such as kubernetes.deployments.restart, query.sql.update, that you define at your desired level of granularity.

At the core of a Tansive session is the Tool Call router. Tools can be added to the router from various sources:

  • Remote MCP Servers: MCP endpoints hosted by external resources that use HTTP Transport (Remote MCP)
  • Local MCP Servers: MCP servers that use stdio transport that access external resources via REST API or any other means such as gRPC. (Local MCP)
  • Local Scripts: Simple run-once-and-exit tools can be written in any language. These tools are run by Tansive with a json argument and the tool prints results to standard output or error.

When a session is created, Tansive automatically creates an MCP endpoint using authenticated HTTP transport.

  • Only the Tools specified by the View policy associated with the session are exposed via the endpoint.
  • The router applies tool input transformations specified in the SkillSet at runtime before tool calls are dispatched.
  • All tool calls, their inputs, and policy evaluation decisions and rules that supported the decision are logged.

Agents can integrate with Tansive in one of two modes:

  • Tansive can run the agent directly subjecting it to the same View policies, therefore providing end to end control over the entire pipeline. In this case, the agent accesses tools via the Tansive SkillSet service which uses a Unix Domain Socket as transport. Upcoming releases will add support for Tansive managed agents to access tools via MCP.

  • Agents are run independently, but Tansive governs tool access. This mode also covers agents in tools such as Cursor, Claude desktop, etc.

🎬 See it in Action​

Policy-governed secure MCP tools proxy for IDEs such as Cursor, Copilot, Claude, etc​

If you are using tools like Cursor, Copilot, Claude, etc with MCP servers such as Github's, read this article on how Tansive can be used to set up use-case or role based policies to defend against unintended agent actions or prompt injection vulnerabilities.

Examples of secure, policy-driven agents​

Below examples show 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)

Example 1: Kubernetes Troubleshooter (Control agent actions via scoped Policy)​

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

Click to expand Kubernetes Troubleshooter Example

Dev Environment

venv-test ❯ tansive session create /demo-skillsets/kubernetes-demo/k8s_troubleshooter \
--view dev-view \
--input-args '{"prompt":"An order-placement issue is affecting our e-commerce system. Use the provided tools to identify the root cause and take any necessary steps to resolve it.","model":"gpt4o"}'

Session ID: 0197a905-8eba-7294-8822-130d2fbb940c
    Start: 2025-06-25 14:36:43.215 PDT

  [00:00.000] [tansive] ▶ requested skill: k8s_troubleshooter
  [00:00.003] [tansive] 🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [kubernetes.troubleshoot] - to use this skill
  [00:00.004] [system.stdiorunner] ▶ running skill: k8s_troubleshooter
  [00:01.256] k8s_troubleshooter ▶ 🤔 Thinking: None
  [00:01.259]  ▶ requested skill: list_pods
  [00:01.259]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [kubernetes.pods.list] - to use this skill
  [00:01.260] [system.stdiorunner] ▶ running skill: list_pods
  [00:01.274] list_pods ▶ NAME                                READY   STATUS    RESTARTS   AGE
                                   api-server-5f5b7f77b7-zx9qs          1/1     Running   0          2d
                                   web-frontend-6f6f9d7b7b-xv2mn        1/1     Running   1          5h
                                   cache-worker-7d7d9d9b7b-pv9lk        1/1     Running   0          1d
                                   orders-api-7ff9d44db7-abcde          0/1     CrashLoopBackOff   12         3h
  [00:01.274] list_pods ▶ # Filter applied: app=ecommerce
  [00:01.274] [system.stdiorunner] ▶ skill completed successfully: list_pods
  [00:06.724] k8s_troubleshooter ▶ 🤔 Thinking: The issue seems to be with the `orders-api` pod, which is in a `CrashLoopBackOff` state. This indicates that the pod is failing to start properly and is repeatedly crashing.

                                   To address this, I will attempt to restart the `orders-api` deployment to see if that resolves the issue.
  [00:06.725]  ▶ requested skill: restart_deployment
  [00:06.725]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [kubernetes.deployments.restart] - to use this skill
  [00:06.727] [system.stdiorunner] ▶ running skill: restart_deployment
  [00:06.747] restart_deployment ▶ deployment.apps/orders-api restarted
  [00:06.747] [system.stdiorunner] ▶ skill completed successfully: restart_deployment
  [00:09.490] k8s_troubleshooter ▶ ✅ Final response: I have restarted the `orders-api` deployment. Please monitor the pod to ensure it transitions to a stable state. If the issue persists, further investigation may be needed to identify underlying problems, such as configuration errors or code issues.
  [00:09.553] [system.stdiorunner] ▶ skill completed successfully: k8s_troubleshooter

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

venv-test ❯ tansive session create /demo-skillsets/kubernetes-demo/k8s_troubleshooter \
--view prod-view \
--input-args '{"prompt":"An order-placement issue is affecting our e-commerce system. Use the provided tools to identify the root cause and take any necessary steps to resolve it.","model":"gpt4o"}'

Session ID: 0197a91d-451d-75a4-894a-f126f909689f
    Start: 2025-06-25 15:02:37.235 PDT

  [00:00.000] [tansive] ▶ requested skill: k8s_troubleshooter
  [00:00.004] [tansive] 🛡️ allowed by Tansive policy: view 'prod-view' authorizes actions - [kubernetes.troubleshoot] - to use this skill
  [00:00.005] [system.stdiorunner] ▶ running skill: k8s_troubleshooter
  [00:01.438] k8s_troubleshooter ▶ 🤔 Thinking: None
  [00:01.440]  ▶ requested skill: list_pods
  [00:01.441]  🛡️ allowed by Tansive policy: view 'prod-view' authorizes actions - [kubernetes.pods.list] - to use this skill
  [00:01.442] [system.stdiorunner] ▶ running skill: list_pods
  [00:01.460] list_pods ▶ NAME                                READY   STATUS    RESTARTS   AGE
                                   api-server-5f5b7f77b7-zx9qs          1/1     Running   0          2d
                                   web-frontend-6f6f9d7b7b-xv2mn        1/1     Running   1          5h
                                   cache-worker-7d7d9d9b7b-pv9lk        1/1     Running   0          1d
                                   orders-api-7ff9d44db7-abcde          0/1     CrashLoopBackOff   12         3h
                                   # Filter applied: app=e-commerce
  [00:01.460] [system.stdiorunner] ▶ skill completed successfully: list_pods
  [00:04.142] k8s_troubleshooter ▶ 🤔 Thinking: The `orders-api` pod is in a `CrashLoopBackOff` state, which likely indicates the issue with the order-placement in your e-commerce system. I'll attempt to restart the `orders-api` deployment to see if that resolves the problem.
  [00:04.143]  ▶ requested skill: restart_deployment
  [00:04.143]  🛡️ blocked by Tansive policy: view 'prod-view' does not authorize any of required actions - [kubernetes.deployments.restart] - to use this skill
  [00:07.646] k8s_troubleshooter ▶ ✅ Final response: I tried to use Skill: functions.restart_deployment for restarting the `orders-api` deployment to resolve the order-placement issue, but it was blocked by Tansive policy. Please contact the administrator of your Tansive system to obtain access.
  [00:07.724] [system.stdiorunner] ▶ skill completed successfully: k8s_troubleshooter

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.

Example 2: Health-Bot (Protect sensitive health data via session pinning)​

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

Click to expand Health-Bot Example

Access John's records but not Sheila's:

tansive session create /demo-skillsets/health-record-demo/health-record-agent \
--view dev-view \
--input-args '{"prompt":"John Doe and Sheila Smith were looking sick. Can you please check their bloodwork and tell me if theres anything wrong?","model":"claude"}'  \
--session-vars '{"patient_id":"H12345"}'

Session ID: 0197e74f-3f06-794e-8a1b-665f861d3586
    Start: 2025-07-07 16:53:39.878 PDT

  [00:00.000] [tansive] ▶ requested skill: health-record-agent
  [00:00.004] [tansive] 🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [patient.labresults.get] - to use this skill
  [00:00.006] [system.stdiorunner] ▶ running skill: health-record-agent
  [00:04.479] health-record-agent ▶ 🤔 Thinking: I can help you check the bloodwork for both John Doe and Sheila Smith. I'll need to look up their information one by one.

                                   Let me start with John Doe:
  [00:04.482]  ▶ requested skill: resolve-patient-id
  [00:04.482]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [patient.id.resolve] - to use this skill
  [00:04.485] [system.stdiorunner] ▶ running skill: resolve-patient-id
  [00:04.559] resolve-patient-id ▶ {
                                     "patient_id": "H12345"
                                   }
  [00:04.562] [system.stdiorunner] ▶ skill completed successfully: resolve-patient-id
  [00:08.541] health-record-agent ▶ 🤔 Thinking: Now I'll retrieve John Doe's bloodwork:
  [00:08.542]  ▶ requested skill: patient-bloodwork
  [00:08.542]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [patient.labresults.get] - to use this skill
  [00:08.551] [system.stdiorunner] ▶ running skill: patient-bloodwork
  [00:08.574] patient-bloodwork ▶ {"patient_id": "H12345", "bloodwork": {"hemoglobin": 13.5, "white_cell_count": 6.2, "platelets": 250, "glucose": 98, "cholesterol": {"total": 180, "ldl": 100, "hdl": 55}}}
  [00:08.577] [system.stdiorunner] ▶ skill completed successfully: patient-bloodwork
  [00:13.690] health-record-agent ▶ 🤔 Thinking: Now let me check Sheila Smith's information:
  [00:13.691]  ▶ requested skill: resolve-patient-id
  [00:13.691]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [patient.id.resolve] - to use this skill
  [00:13.692] [system.stdiorunner] ▶ running skill: resolve-patient-id
  [00:13.746] resolve-patient-id ▶ {
                                     "patient_id": "H23456"
                                   }
  [00:13.749] [system.stdiorunner] ▶ skill completed successfully: resolve-patient-id
  [00:18.895] health-record-agent ▶ 🤔 Thinking: Now I'll retrieve Sheila Smith's bloodwork:
  [00:18.896]  ▶ requested skill: patient-bloodwork
  [00:18.896]  🛡️ allowed by Tansive policy: view 'dev-view' authorizes actions - [patient.labresults.get] - to use this skill
  [00:18.897]  ❗ unable to transform input
                                    Error: Unauthorized to access patient bloodwork for patient H23456
  [00:28.640] health-record-agent ▶ ✅ Final response: Here's what I found:

                                   **John Doe (Patient ID: H12345)**
                                   Based on the bloodwork results, John Doe's values appear to be within normal ranges:
                                   - Cholesterol: Total 180 mg/dL (desirable is <200)
                                   - HDL: 55 mg/dL (optimal is >40)
                                   - LDL: 100 mg/dL (optimal is <100)
                                   - Glucose: 98 mg/dL (normal fasting is 70-99)
                                   - Hemoglobin: 13.5 g/dL (normal for adult males is typically 13.5-17.5)
                                   - Platelets: 250 × 10^3/μL (normal range is 150-450)
                                   - White cell count: 6.2 × 10^3/μL (normal range is 4.5-11.0)

                                   John's bloodwork appears normal with no concerning values.

                                   **Sheila Smith (Patient ID: H23456)**
                                   I was unable to access Sheila's bloodwork records. It appears you may not have authorization to view this patient's bloodwork information. You may need to request proper authorization to access her medical records.
  [00:28.727] [system.stdiorunner] ▶ skill completed successfully: health-record-agent

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.