Itential Gateway

The Governed Execution Engine for Infrastructure Automation

Itential Gateway runs your Ansible playbooks, Python scripts, and OpenTofu plans as governed, callable services. Git-native content, ephemeral runtimes, secrets injected at execution, and one governance model for every consumer: workflows, pipelines, engineers, and AI agents.

Request a Demo Read the White Paper

The Automation Engineering Tax

From Scattered Scripts to Governed Automation Services

From Vibe-Coding to Self-Service: Turning Code Into Products

No Standard Execution Environment

Scripts run wherever they were written: a shared jump host, a personal venv, a Jenkins node nobody patches. Every environment drifts differently, and production finds them first.

Ungoverned Access

Whoever has the SSH keys can run anything against anything. No RBAC, no approval gates, no blast-radius control on the scripts that touch production infrastructure.

No Audit Trail

When something changes, nobody can prove who ran what, when, or why. Evidence gets reconstructed from shell history and chat threads after the fact.

DIY Wrapper Debt

Flask apps, Jinja2 templates, and cron jobs built just to expose scripts as services. Custom code your team owns, maintains, and debugs forever.

The Execution Layer

What Is Itential Gateway?

Itential Gateway is the distributed execution engine of the Itential Platform. It is software you deploy in your own environment, close to the infrastructure it acts on, that runs your automation content: Ansible Playbooks, Python scripts, and OpenTofu Plans. The Platform decides what should happen and when. The gateway is where the work actually runs, inside your network, next to your devices and systems, with your credentials. Every execution pulls code from Git, builds a clean ephemeral runtime, injects secrets, executes, writes the audit trail, and destroys the environment. Once onboarded, every automation becomes a callable, governed service: one automation, every consumer.

Read the Documentation

By Design, Not by Default

What Makes Itential Gateway Different

Everything in Itential Gateway follows from four deliberate design decisions. They are the reason the gateway scales horizontally, operates lights-out, and connects to a cloud platform without a VPN.

Read the White Paper

Content Lives in Git

The gateway stores only operational state. Every script, playbook, and plan lives in your Git repositories and is retrieved at execution time. Add capacity by pointing a new runner at the cluster: nothing to synchronize.

GitOps Is the Architecture

Configuration is code. DSL files describe every resource, so promotion from dev to stage to prod is a merge, not a rebuild. Your pipelines run the gateway, not the other way around.

No Web UI, On Purpose

A gateway UI is an attack surface and an invitation to manage servers by hand. The gateway runs lights-out: pipelines operate it, the iagctl CLI administers it, and visibility lives in Gateway Manager.

User TLS, Not VPN Tunnels

The gateway dials out to the Platform over WebSocket secured with user TLS. No inbound firewall rules, no site-to-site tunnels, no IT project. Both sides authenticate with certificates.

Key Capabilities

What Itential Gateway Does

Everything below runs through the same engine. Git sync brings your automations in, ephemeral runtimes execute them, secrets inject at runtime, and one governance model covers every consumer, from engineers and pipelines to agents and external AI.

Git Sync & Decorators

Bring Your Own Automations

Every Python script, Ansible Playbook, OpenTofu Plan, Nornir module, Netmiko script, and Scrapli interaction your team has already built can be onboarded without modification. Connect to your Git repository (GitHub, GitLab, or Bitbucket) and Itential Gateway syncs automatically. Apply a JSON schema decorator to any automation to auto-generate a REST API endpoint. A personal script becomes a callable, governed service, with one RBAC model, one audit trail, and one secrets layer regardless of which executor runs.

Productize Your Network Automations as Services

Decorators: JSON Schema to REST API in Minutes

Define input parameters using a JSON schema decorator. Itential Gateway auto-generates a documented REST API endpoint callable by workflows, agents, and CI/CD pipelines.

Real-Time Git Sync: Always Current

Itential Gateway connects directly to your Git repository. Every execution runs the latest committed version. No manual deploys. No version drift.

One RBAC Model, Every Executor

Access controls, secrets injection, audit logging, and approval gates apply consistently across Python, Ansible, OpenTofu, Nornir, Netmiko, and Scrapli. Same governance model, every execution type.

Since we deployed Itential, the speed at which we are developing automations and innovation has increased massively.

Shirish Basant Rai

Network Platforms & Systems Architect, Colt

Ephemeral Runtimes

Consistent Execution, Zero Dependency Management

The execution environment problem is one of the biggest hidden taxes in network automation engineering: shared virtual environments, dependency conflicts between Ansible collections, Python version mismatches that break playbooks in production but not in development. Itential Gateway eliminates this entirely by creating a dedicated ephemeral runtime environment for every execution. Dynamically built, always consistent with the committed automation version, destroyed after execution completes. Concurrent executions never conflict.

Ephemeral Environments Per Execution

Every execution gets its own dynamically created runtime with the correct Python version and dependencies, built instantly and destroyed after completion. No shared state between executions.

Concurrent Execution Without Conflict

Run the same playbook against 500 devices simultaneously, each execution fully isolated. Failures in one execution don’t affect any other.

No Server or Environment Maintenance

Itential Gateway manages runtime creation automatically. No shared venvs to maintain, no server patching cycles disrupting automation, no dependency upgrade coordination across teams.

Secrets & Credentials

Credentials Injected at Runtime, Never Exposed

Device credentials, API keys, vault tokens. The things every automation needs and the things that never belong in a script. Itential Gateway integrates with HashiCorp Vault, CyberArk, AWS Secrets Manager, and its own secrets store, retrieving the right credentials at runtime and injecting them into each ephemeral execution environment. Engineers reference secrets by name in decorators. Itential Gateway handles the rest. Secrets never appear in automation files, in execution logs, or in Job Viewer output.

Native Integration With Vault, CyberArk, AWS Secrets Manager

Itential Gateway integrates directly with HashiCorp Vault, CyberArk, AWS Secrets Manager, and its own native secrets store. Use the secrets management system your security team already approves.

Runtime Injection, Per-Execution Scope

Secrets are retrieved at execution start, injected into the ephemeral runtime as environment variables or Ansible vault variables, and discarded when the runtime is destroyed. Each execution sees only the credentials it needs.

Never Stored in Files or Logs

Secrets never live in scripts, playbooks, decorators, or Git. Never appear in execution logs. Never show up in Job Viewer output. Auditors get attribution. Engineers don’t get blast radius.

Callable as Services

Every Automation Available to Agents, Workflows & Pipelines

An automation isn’t valuable until other things can call it. Every automation onboarded through Git sync or generated by a Builder Skill is automatically registered as a callable service across the platform. FlowAgents add it to their tool library. Workflows invoke it as a governed step. CI/CD pipelines hit it as a REST endpoint. Engineers can still run it from the iagctl CLI. One automation, every consumer.

FlowAgent Tool Library Registration

Every automation is registered in the FlowAgent tool library with structured inputs and outputs. Agents include them in their allowlisted skill set, call them with reasoned inputs, and observe the structured result. Agents reason. Automations execute.

REST API Endpoint Per Automation

Every decorated automation auto-generates a documented REST API endpoint. Callable from CI/CD pipelines, ITSM platforms, monitoring tools, or any system that speaks HTTP, with schema validation, RBAC, and audit logging applied automatically.

FlowMCP Gateway for External AI

FlowMCP Gateway, part of Itential Gateway, connects external AI systems inbound: virtual MCP servers scoped per persona, RBAC on every tool, and audit at every handoff. Start with the open-source Itential MCP Server for a single model. Bring your own AI. Govern every action.

Built to Scale With You

Deploy Anywhere, Managed from One Place

Itential Gateway ships as a single binary and a container image, with five deployment models that grow with you: from a single all-in-one node, to highly available clusters with dedicated runner nodes, to multiple independent clusters across regions and network segments. However you deploy, management stays centralized in the Itential Platform.

Read the White Paper

Five Deployment Models

Start simple on a single node. Add high availability, dedicated runners for distributed execution, or multiple independent clusters for geo-distributed and segmented environments. Architecture evolves without rework.

Gateway Manager

The platform application that connects gateway clusters to the Itential Platform. Services are discovered automatically, appear in the workflow palette, and are protected from silent breakage when they change.

Inventory Manager

One platform-managed inventory layer for every automation target. Federates from the systems you already trust, like NetBox, ServiceNow, and CMDBs. Your sources of record stay the source of truth.

The AI Integration Layer

FlowMCP Gateway: Connect AI, Govern Every Action

FlowMCP Gateway is part of Itential Gateway. It extends the gateway’s governed execution layer into the Model Context Protocol ecosystem, in both directions. Automations and FlowAgents invoke external MCP tools for intelligence enrichment. External AI systems access your automations as callable skills. The principle is the same either way: AI requests intent, and the gateway determines what actually runs. No AI system gets direct access to infrastructure or credentials.

See How FlowMCP Works

Automations Call External AI

Automations and FlowAgents invoke external MCP tools and vendor agents, like NetBox MCP and Selector MCP, for data and intelligence enrichment during execution. Callable, never unbounded.

External AI Calls Your Automations

Virtual MCP servers scoped per AI system, team, or persona. RBAC on every tool, complete audit logging at every AI-to-platform handoff. Each connected AI sees only what it is allowed to see.

Open Source to Enterprise

Start with the open-source Itential MCP Server to connect a single model. Move to FlowMCP Gateway for centralized governance across multiple MCP instances, personas, and teams in production.

Spec-Driven Development

Generate Production Automations From Plain Language

Itential Builder Skills are AI agent skills available on the Anthropic Marketplace that let any team generate automation artifacts from plain language. Describe what you need: a Python script to collect show command output, an Ansible playbook to push a software upgrade, an OpenTofu plan to provision a VPC. The Builder Skill generates the artifact, commits it to your Git repository, and Itential Gateway syncs it automatically. Immediately executable, governed, and callable by workflows, agents, and pipelines from the first run.

Explore Itential Builder Skills

Itential Builder Skills on the Anthropic Marketplace

AI agent skills that generate real Python scripts, Ansible playbooks, and OpenTofu plans through the platform’s REST APIs. Available today, installable in minutes.

Git-Native, Immediately Executable

Every Builder Skill commits its output to your Git repository. Itential Gateway syncs automatically, running the latest committed version without a manual deploy step.

Same Governance From Run One

Builder-Skill-generated automations are governed identically to hand-built ones: RBAC, secrets injection, audit trails, callable by workflows and agents from the first execution.

Use Cases

From Script to Governed Service

Every example below runs through the same governed execution layer: ephemeral runtime, injected secrets, RBAC enforced, audit trail attached. Whether the automation came from your existing Git repo, a Builder Skill, or both, every execution looks the same to operators, agents, and auditors. Same engine. Same governance. Every run.

Watch the Demo

Bring Your Own Automation

Onboard Years of Automation Work Without Rewriting It

Connect your existing Ansible, Python, OpenTofu, Nornir, Netmiko, and Scrapli repos. The Gateway syncs the entire library, applies JSON schema decorators, and turns every script and playbook into a callable governed service. Engineers keep working in their IDE. The team gets governance, RBAC, and audit on every execution overnight.

Watch the Demo

Spec-Driven Development

Generate a Production Automation From a Plain-Language Spec

An engineer describes the automation they need to an AI assistant powered by an Itential Builder Skill. The Skill generates the Ansible playbook or Python script, commits to Git, and the Gateway syncs and runs it within minutes. From spec to a real, governed automation, no engineer building anything from scratch.

Watch the Demo

Ephemeral Runtimes

10,000 Concurrent Executions, Zero Dependency Conflicts

A PSIRT-driven remediation runs the same Python script against 10,000 devices simultaneously. Each execution gets its own ephemeral runtime with the right dependencies. Credentials inject per execution from Vault. Failures in one execution don’t affect any other. No shared venvs, no version drift, no late-night dependency triage.

Watch the Demo

Callable as Services

Every Automation Reachable from Agents, Workflows, AI & Pipelines

A FlowAgent calls a Python script from its tool library. A workflow invokes the same script as a governed step. A CI/CD pipeline hits it as a REST endpoint. An external LLM accesses it through FlowMCP Gateway. One automation. Every consumer. Every execution governed identically.

Watch the Demo

Get Started

End the Script Sprawl

Personal Python scripts. One-off Ansible playbooks. Jenkins jobs nobody owns. See how Itential Gateway standardizes the chaos and makes every automation a callable, governed service.

Talk to an Expert

Keep Learning

Dive Deeper into Itential Gateway

Guides & Whitepapers

Itential Gateway 5: The Governed Execution Engine for Infrastructure Automation

Frequently Asked Questions

–+

The DIY approach to turning Python scripts and Ansible playbooks into callable services means building and maintaining the execution layer yourself: Flask apps to expose scripts as APIs, Jinja2 templates for input rendering, virtual environment management per automation, custom RBAC bolted on top, audit logging built from scratch, and a Jenkins job or cron script acting as a pseudo-execution layer. Every one of those components is custom code your team owns, maintains, and debugs when something breaks in production. Itential Gateway replaces that entire stack. JSON schema decorators auto-generate REST APIs for any script, playbook, or plan. Ephemeral runtimes eliminate venv management. RBAC, secrets injection, and audit logging apply automatically to every execution. Spec-Driven Development generates new automations from plain language without writing a line of code. The automation engineering tax disappears entirely.

–+

Ansible Automation Platform is an excellent managed execution environment for Ansible. It handles playbook execution, inventory management, scheduling, and basic RBAC well within the Ansible ecosystem. Where it falls short: it’s Ansible-specific. Python scripts, OpenTofu plans, Nornir modules, Netmiko scripts, and Scrapli interactions require separate execution infrastructure outside AAP. There’s no Spec-Driven Development capability to generate playbooks from plain language and commit them to Git automatically. And there’s no native path for FlowAgents to invoke playbooks as governed tools through an MCP interface. Itential Gateway runs Ansible alongside every other automation type under one governance model, and existing playbooks from AAP can be called as governed steps inside Itential workflows without modification.

–+

Nautobot and NetBox are network source of truth and IPAM platforms. They track what your network looks like, store inventory, and model network data. Network to Code builds and maintains these platforms and provides professional services around them. None of them are automation execution platforms. They don’t execute Python scripts or Ansible playbooks, govern who can run what automation against which devices, create ephemeral runtime environments, or expose automations as governed REST API endpoints callable by agents and pipelines. Itential complements Nautobot and NetBox directly: Itential Gateway queries them for device inventory and configuration intent via REST API, then executes governed automations against the devices those platforms track.

–+

Every automation engineering capability is exposed as a documented REST API endpoint, and the Itential MCP Server exposes those APIs as callable skills for any connected LLM. Describe the automation you need: its purpose, the devices it targets, the inputs it requires, the expected output. The LLM calls those APIs to generate the automation artifact, a real Python script, Ansible playbook, or OpenTofu plan, and commits it to your Git repository automatically. Itential Gateway syncs it immediately. It’s executable, governed, and callable from the first run, and the output is identical to a hand-built automation in every technical respect: same file format, same Git workflow, same execution behavior, same governance.

–+

Secrets, including device credentials, API keys, and vault tokens, are never stored in automation files or passed as plain text inputs. Itential Gateway integrates with HashiCorp Vault, CyberArk, AWS Secrets Manager, and its own native secrets store, and injects the correct credentials at runtime for every execution. Engineers define which secret a decorator input maps to at configuration time. At execution time, Itential Gateway retrieves the secret and injects it into the runtime environment, where the automation accesses it as an environment variable or Ansible vault variable. Secrets are never exposed in execution logs, never visible in Job Viewer output, and never accessible beyond the scope of the execution that required them.

–+

Every decorated automation is automatically registered as a callable tool in the FlowAgent tool library, with a structured input schema, a defined output schema, and governed execution. When a FlowAgent reasons through a goal that requires running an automation, like collecting show command output from a device group, pushing a configuration change, or running a validation script, it calls the automation tool with structured inputs from its allowlisted skill set. Itential Gateway creates an ephemeral runtime, runs the automation with injected secrets, captures the output, and returns it as structured data to the agent’s reasoning loop. The agent uses the output to continue reasoning: deciding the next step, evaluating the result, or triggering a follow-on workflow. The agent never touches infrastructure directly. Itential Gateway controls what actually runs.

–+

Itential Gateway can run independently as a standalone execution engine, administered through the iagctl CLI and callable from pipelines and APIs. Connecting it to the Itential Platform through Gateway Manager is what adds service discovery inside workflows, service lifecycle protection, Service Groups, and consumption by FlowAgents.

–+

No. Itential Gateway initiates an outbound connection to the Platform over WebSocket secured with user TLS. Traffic flows through standard firewalls, no inbound rules or site-to-site tunnels are required, and both sides authenticate with certificates. Either side can terminate the connection.