Intent-Aware Runtime Governance for AI Agents

Synentra™ sits between autonomous AI agents and the APIs and tools they interact with, providing runtime governance and enforcement for every request. It evaluates request context, classifies likely intent, applies policy and risk controls, and allows, denies, or pauses high-risk actions for human approval.

Documentation · Quick Start · Discord · Discussions

An AI agent sends a request:

DELETE http://localhost:7080/proxy/https://localhost:8080/v1/customers?status=inactive
Synentra-Authorization: Bearer <agent-token>
Content-Type: application/json

{
  "instruction": "Clean up old customer accounts"
}

Synentra evaluates the request:

Agent       : customer-maintenance-agent
Intent      : destructive_delete
Risk Score  : 0.91
Decision    : Human approval required

A traditional API gateway can authenticate the caller and match the HTTP method and path.

Synentra additionally evaluates the request context and likely intent before deciding whether the action should proceed.

For start Synentra:

docker run --name synentra -p 7080:7080 ghcr.io/synentra/synentra:latest

Synentra will be available at:

http://localhost:7080

Production deployments require an appropriate security configuration, including token issuance and secret management. See the Security configuration documentation before deploying Synentra in production.

To provide your own configuration file:

docker run \
  --name synentra \
  -p 7080:7080 \
  -v "$(pwd)/appsettings.json:/app/appsettings.json:ro" \
  ghcr.io/synentra/synentra:latest

For a complete Docker setup, see the Synentra Docker Deployment documentation.

Pre-built binaries for supported platforms are available on the Releases page.

Download and extract the appropriate archive for your platform.

On Linux:

tar -xzf synentra-linux-x64.tar.gz
chmod +x synentra
./synentra

On Windows:

.\synentra.exe

Prerequisite: .NET 10 SDK

git clone https://github.com/synentra/synentra.git
cd synentra

dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release

dotnet run --project src/Synentra --configuration Release

AI agents can make authenticated and technically valid API requests while still taking actions that are unintended, excessive, or dangerous.

Traditional gateways primarily answer questions such as:

• Is the caller authenticated?
• Is the caller authorized to access this route?
• Is the request within its rate limit?

Synentra adds another governance layer:

• What is the agent likely trying to accomplish?
• How risky is this action in the current context?
• Does the request comply with behavioral and semantic policies?
• Should this action require human approval?
• Has the agent's previous behavior reduced its trust level?

Synentra evaluates request context such as the HTTP method, path, payload, agent identity, and configured policy state. Local inference keeps request data inside your environment and avoids requiring an external classification API.

Synentra combines deterministic policy rules with semantic conditions.

Policies can evaluate:

• Agent identity and attributes
• HTTP method and path
• Request headers and payload
• Classified intent
• Confidence level
• Risk score
• Historical behavior

Policies can return one of three primary outcomes:

Allow
Deny
HITL (Require human approval)

Synentra evaluates contextual risk signals for each request.

These signals can include:

• HTTP method
• Target path
• Request body characteristics
• Time-based conditions
• Agent history
• Anomaly signals
• Previous policy violations
• Previous HITL decisions

Agent trust can evolve over time based on observed behavior. Agents that fall below a configured trust threshold can be quarantined until manually reviewed.

High-risk or ambiguous requests can be suspended before they reach the upstream API.

A reviewer can:

• Inspect the request and decision context
• Approve the action
• Deny the action
• Record the reason for the decision

Synentra can notify reviewers through:

• Slack
• Microsoft Teams
• PagerDuty
• Generic webhooks

Synentra associates requests and decisions with registered agent identities.

Audit records can include:

• Agent identity
• Request metadata
• Classified intent
• Classification confidence
• Risk score
• Policy result
• HITL status
• Reviewer decision
• Final routing outcome

Synentra supports structured logging and distributed observability for governance decisions and request processing.

Supported capabilities include:

• Structured application logs
• File and console logging
• OpenTelemetry export
• Audit records
• Health endpoints
• Decision and latency telemetry

Each inbound request passes through the Synentra governance pipeline.

Synentra first validates the request and its caller.

This stage can include:

• API version validation
• Agent authentication
• JWT validation
• Rate limiting
• Request-size limits

Requests that fail validation are blocked and recorded.

Valid requests are evaluated through the governance pipeline.

Configured policies evaluate the agent, request, environment, and available semantic context.

A policy can immediately allow, deny, or require human approval.

Risk calculators evaluate contextual signals such as the HTTP method, target path, payload characteristics, request timing, agent history, and anomaly indicators.

The semantic provider classifies the likely intent of the request and returns a confidence score.

The resulting intent can be used by policies and the final decision process.

The request receives one of the following outcomes:

• ✅ Allow — the request is forwarded to the upstream service.
• ⏳ Pending review — the request is suspended until a reviewer approves or denies it.
• 🚫 Block — the request is rejected before reaching the upstream service.

Each outcome is recorded for auditing and observability.

• Intent-aware request evaluation using local semantic classification
• Deterministic and semantic policies for context-aware enforcement
• Risk scoring using configurable request and behavioral signals
• Dynamic agent trust based on historical behavior
• Human-in-the-loop workflows for sensitive actions
• Multi-channel HITL notifications
• Agent quarantine for identities that fall below a trust threshold
• Per-agent audit trails
• Structured logging and OpenTelemetry support
• Memory and Redis caching
• SQLite and PostgreSQL storage options
• External identity provider integration
• Local operation without a required cloud classification service

Synentra is not intended to replace every component in an AI or API platform.

It is not:

• A general-purpose LLM proxy
• A token accounting or prompt-caching platform
• An OpenAI API cost-management service
• A load balancer
• A canary deployment system
• A replacement for your identity provider
• Limited to MCP servers or a specific agent framework

Synentra governs AI-agent actions against HTTP APIs and can be used with LangChain, Semantic Kernel, custom agents, MCP-based systems, and other frameworks.

Add a centralized governance layer between AI agents and internal APIs without implementing separate controls in every service.

Apply policies using agent identity, request context, likely intent, risk, and historical behavior.

Integrate agents with one governance gateway instead of building policy enforcement, risk evaluation, audit logging, and approval workflows independently.

Use policy decisions, human approvals, and audit records as technical controls that can support broader organizational governance and compliance programs.

Synentra provides technical governance controls. Using Synentra alone does not establish compliance with standards or regulations such as SOC 2 or HIPAA.

Synentra is designed for low-latency, local request evaluation.

Performance depends on factors including:

• Hardware
• Model configuration
• Payload size
• Enabled policies
• Storage provider
• Cache provider
• Logging configuration
• Semantic provider

Published performance results should be interpreted together with their test environment and benchmark methodology.

See the documentation for current performance measurements and configuration guidance:

Performance documentation

The project roadmap describes planned capabilities, upcoming releases, and longer-term direction.

👉 View the Synentra roadmap

Full documentation is available at:

https://synentra.io/docs

Useful starting points:

• Getting Started
• System Configuration
• Security Configuration
• Semantic Configuration
• Policy Configuration
• HITL Configuration
• Observability
• OWASP ASI Control Coverage Matrix

Security is a core concern for Synentra. The project follows a responsible disclosure process for reported vulnerabilities.

Do not report security vulnerabilities through a public GitHub issue.

Use one of the following private channels:

• GitHub Private Vulnerability Reporting: Report a vulnerability

• Email: [email protected] Subject: [Synentra] Security Vulnerability

Include, where possible:

• A description of the vulnerability
• Its potential impact
• Steps to reproduce
• A proof of concept
• Relevant environment information
• The affected Synentra version

We aim to acknowledge security reports within 48 hours and provide an initial remediation timeline within several days.

Supported versions and the complete disclosure process are documented in:

SECURITY.md

Synentra uses:

• FOSSA for dependency license and vulnerability analysis
• SonarCloud for static analysis, reliability, maintainability, and security checks

Additional project-health badges are available in the Project Health section.

Synentra is developed in the open. Contributions may include code, tests, documentation, integrations, issue reports, feature proposals, and design discussions.

• 🐛 Report a bug
• 💡 Request a feature
• 🔍 Browse good first issues
• 📖 Improve the documentation
• 🧪 Add tests and examples
• 🔌 Propose or implement integrations
• 💬 Join project discussions

1. Fork the repository.
2. Create a branch from main.
3. Implement the change.
4. Add or update tests.
5. Run the test suite:

dotnet test --configuration Release

6. Open a pull request against main with a clear explanation of the change.

Read CONTRIBUTING.md before submitting a pull request.

• Discord: https://discord.synentra.io
• GitHub Discussions: https://github.com/synentra/synentra/discussions
• Documentation: https://synentra.io/docs

Project governance and maintainer responsibilities are documented in:

• GOVERNANCE.md
• MAINTAINERS.md
• CODE_OF_CONDUCT.md
• ROADMAP.md

Synentra is open source and licensed under the Apache License 2.0.

Some dependencies use other open-source licenses. Their notices and attribution requirements are documented in:

THIRD-PARTY-NOTICES.md

Synentra™ and the Synentra logo are trademarks claimed by Amin Ziagham.

The Synentra source code is licensed under the Apache License 2.0. The license does not grant permission to use the Synentra name or logo in a way that implies endorsement, affiliation, sponsorship, or that a modified distribution is an official Synentra product.

See TRADEMARKS.md for trademark usage guidelines.

If Synentra solves a problem for your team, consider starring the repository. It helps other developers discover the project and follow its development.

Thanks to all the contributors who help make Synentra better! ❤️