Synentra
Intent-Aware Runtime Governance for AI Agents
Synentra is an open-source governance runtime built on .NET 10. It controls how AI agents invoke registered HTTP APIs and MCP tools.
Agents submit operations and arguments through Synentra. The runtime resolves the caller’s identity and security scope, evaluates governance rules, and decides whether to allow the action, require human approval, or deny it. Admitted invocations enter durable execution with an immutable snapshot of the authorized operation and target.
The governance model
Synentra uses a versioned GovernanceBundle to define the actions agents can request and the rules governing those actions.
| Concept | Purpose |
|---|---|
| Operation | Defines an action, its input schema, mutability, execution model, and governance requirements. |
| Target | Registers an HTTP API or MCP server, its adapter, and optional credential and response-retention settings. |
| Binding | Maps an operation and its arguments to a target’s HTTP request or MCP tool. |
| Profile | Configures intent, trust, risk, and policy evaluation for an operation. |
| Policy and restriction | Determines which actions are permitted, denied, or subject to review. |
| Task grant | Provides scoped, time-bounded authority for operations that require a grant. |
Administrators validate, store, and activate bundles through the manifest API. The active bundle supplies the governance configuration used during evaluation and admission.
Key capabilities
| Capability | Description |
|---|---|
| Registered operations | Agents invoke defined operations whose bindings identify the upstream target and transport. |
| Identity and scope | Resolves authenticated callers through configured identity providers and associates invocations with agent identities and security scopes. |
| Governance decisions | Evaluates restrictions, policy, trust, risk, and available intent evidence to return allow, review, or deny. |
| Human approval | Pauses invocations for review and revalidates authority when approved invocations resume. |
| Durable execution | Persists execution snapshots and outbox records so workers can claim and dispatch admitted work. |
| HTTP and MCP adapters | Executes authorized operations against registered HTTP APIs and MCP servers. |
| Credential management | Resolves credentials through target bindings, with separate bootstrap, startup, and runtime secret-resolution stages. |
| Outbound security | Checks authorized destinations, validates resolved network addresses, disables automatic redirects, and requires HTTPS for credential-bearing calls. |
| Response retention | Applies target-specific retention rules, including JSON property allowlists. |
| Audit and execution records | Records governance decisions, approvals, execution state, and outcomes for inspection and reconciliation. |
SQLite and PostgreSQL provide persistence options. Credential-provider implementations include LocalVault, HashiCorp Vault, Azure Key Vault, and AWS Secrets Manager.
How Synentra works
The runtime organizes request processing into request evaluation, durable admission, and governed execution.
Request evaluation
REST and MCP clients submit requests through the API ingress. Synentra resolves the authenticated agent and security scope, selects the registered operation and binding, and normalizes the arguments.
The governance engine applies restrictions and the operation’s configured controls.
| Decision | Behavior |
|---|---|
| Allow | Proceed to admission. |
| Review | Pause the invocation for human approval. |
| Deny | Stop the invocation before dispatch. |
For a review decision, an authorized reviewer approves or rejects the request. An approved invocation must resume through admission, where Synentra checks its authority again. A rejected invocation stops.
Caller-provided purpose and workflow information contribute context to evaluation. Authentication establishes the caller’s identity and scope.
Durable admission
The admission service captures the authorized operation, target, manifest revision, and credential-binding authority in an immutable execution snapshot. It persists the execution claim and outbox work for processing.
The execution worker claims queued work and revalidates dispatch authority. Changes to the active manifest, credential binding, task grant, or quarantine state can prevent queued work from executing.
Governed execution
The selected HTTP or MCP adapter constructs the outbound call from the admitted snapshot. Credential resolution supplies the target’s configured credentials.
Before the call reaches a registered target, outbound controls check the authorized destination and operation, validate DNS and IP addresses, enforce redirect restrictions, and require HTTPS when credentials are attached.
The runtime persists the transport result. If a call may have reached its target but its result is uncertain, execution can enter an unknown state. The execution API supports reconciliation of these outcomes. The worker avoids automatic redelivery after committing dispatch ownership.
Data and observability
The data and governance stores persist active bundles, targets, credential bindings, task grants, approvals, execution state, and audit records.
Structured application logging and audit APIs support investigation of request decisions and execution outcomes. Health checks report database and active-manifest readiness.
Current implementation status
The current v2 implementation includes the governance, admission, approval, execution, adapter, and credential components described above. Two integration points require additional implementation or startup wiring:
- Semantic classification. The registered
default-semanticprovider currently returns an unavailable/error result. Profiles control how required intent failures affect governance decisions. Semantic classification requires a working intent-provider implementation. - OpenTelemetry. Configuration and integration code exist, but the startup call that enables OpenTelemetry is currently commented out.
Who uses Synentra?
- Platform engineers centralize governance across agent integrations and registered tools.
- Security architects define permitted operations, approval requirements, credential access, and outbound restrictions.
- Agent developers submit operations through a shared runtime that coordinates authorization and execution.
- Governance teams inspect policy decisions, human approvals, and audit records associated with agent actions.
Get started
Configure an identity provider, persistence, secret management, and outbound network settings. Then validate and activate a GovernanceBundle containing the operations and targets your agents will use.
The current interfaces use these contracts:
| Interface | Contract |
|---|---|
| REST APIs | /v2 |
| Invocation submission | POST /v2/invocations |
| Invocation status | GET /v2/invocations/{id} |
| Approval and resume | /v2/approvals and POST /v2/invocations/{id}/resume |
| Manifest management | /v2/manifests |
| MCP gateway | /mcp/{serverId} |
| Invocation schema | synentra.invocation.v2 |
| GovernanceBundle API version | synentra.io/v2alpha2 |
An invocation identifies a registered operation, supplies its arguments, and can include a binding ID or task grant. Mutation invocations require an idempotency key.
Admission can return 202 Accepted while execution is pending. Follow the invocation resource to inspect its decision, approval, execution status, and outcome.
The checked-in development configuration uses http://localhost:7080. A running instance exposes its OpenAPI UI at /open-api and health endpoint at /health.
License
Synentra is open source and licensed under the Apache License 2.0. Dependency notices and attribution requirements are documented in the repository’s THIRD-PARTY-NOTICES.md.