Nexara is the capability layer for AI products that need to use real tools without turning every integration into a security project. It gives agents and assistants a signed, policy-aware way to discover skills, rank the right tool, request secrets, call remote capabilities, and leave behind an audit trail that hosts can actually trust.
Use Nexara when your AI system is ready to move beyond hard-coded tool lists, but you still need crisp boundaries around what can be installed, exposed, and executed.
Nexara can compile plain policy intent into inspectable runtime contracts:
reads orders, never refunds
That sentence becomes explicit allow, deny, and confirmation rules over semantic
capabilities such as orders.read, orders.search, orders.export, and
orders.refunds.create. Hosts can simulate the contract against a catalog before
shipping it, require signed policy contracts for enterprise review, and receive
runtime audit explanations when calls are allowed, denied, or confirmation-gated.
- signed skill registries and installable capability packs
- one-line policy authoring through opt-in
nexara-policy - inspectable and signable policy contracts
- product-neutral
host_requirementsinstead of app-specific compatibility fields - remote tool discovery and execution contracts
- bounded tool selection for model prompts
- trust-tier, scope, action-class, confirmation, payload, and concurrency policy
- sync and async secret-store contracts
- structured audit records with redacted outputs and secret names only
- optional learned usage signals that can improve ranking without overriding policy
- Qwen-family MCP configuration import through
nexara-compat-qwen - an authenticated HTTP server with tool and skill-admin APIs
At runtime, the host owns execution and context. Nexara owns the capability contract: it assembles descriptors, verifies registry metadata, decides what is visible to the model, enforces policy before calls, and emits audit records.
crates/nexara: facade crate and feature bundlecrates/nexara-core: core tool descriptors, broker, registry, policy, audit, validation, and errorscrates/nexara-policy: deterministic one-line policy compiler, catalog simulator, and signed policy contract helperscrates/nexara-cli: command-line policy compile, simulate, sign, and verify toolscrates/nexara-registry: signed skill indexes, manifests, installed-skill stores, and file/HTTP sourcescrates/nexara-secrets: sync and async secret-store traits, redacted values, memory and encrypted-file storescrates/nexara-remote: remote endpoint contracts, allowlists, auth providers, diagnostics, and HTTP client helperscrates/nexara-runtime: host-neutral runtime for policy checks, brokered listing, calls, limits, and auditcrates/nexara-learning: bounded ranking-signal contracts and adjustment enginecrates/nexara-learning-memory: in-memory usage-signal storecrates/nexara-learning-jsonl: append-only local usage-signal storecrates/nexara-learning-sled: embedded durable usage-signal storecrates/nexara-compat-qwen: Qwen-family prompt profile detection and MCP config importcrates/nexara-server: authenticated HTTP service and admin skill install/list APIsexamples/policy-shop: runnable one-line policy demo forreads orders, never refundssdk/javascript: small JavaScript client for list/call flowsdocs: architecture, deployment, manifest, remote protocol, threat model, and release validationdocs/qwen-compatibility.md: Qwen MCP import and approval-store mapping
The facade crate keeps the public import surface small while allowing hosts to avoid unused dependencies.
[dependencies]
nexara = { version = "0.1", features = ["runtime", "registry", "secrets"] }Available facade features:
registryremotesecretsruntimelearninglearning-memorylearning-jsonllearning-sledcompat-qwenserverpolicyall
use async_trait::async_trait;
use nexara_core::{ToolCallRequest, ToolCallResult, ToolDescriptor, TrustProfile};
use nexara_runtime::{
HostToolExecutor, NexaraRuntime, NexaraRuntimeConfig, StaticToolCatalog,
StaticTrustPolicyResolver,
};
use serde_json::json;
use std::sync::Arc;
#[derive(Clone)]
struct Context;
struct Executor;
#[async_trait]
impl HostToolExecutor<Context> for Executor {
async fn call_host_tool(
&self,
_tool: &ToolDescriptor,
request: ToolCallRequest,
_context: Context,
) -> Result<ToolCallResult, nexara_core::NexaraError> {
Ok(ToolCallResult {
result: json!({ "echo": request.params }),
})
}
}
let tool = ToolDescriptor::read_only("echo", "Echo input for diagnostics");
let runtime = NexaraRuntime::new(
NexaraRuntimeConfig::default(),
Arc::new(StaticToolCatalog::new(vec![tool])),
Arc::new(Executor),
Arc::new(StaticTrustPolicyResolver::new(TrustProfile::Observe)),
);Nexara manifests use product-neutral host requirements:
name = "example.search"
version = "0.1.0"
publisher = "example"
description = "Searches an example corpus"
license = "MIT"
runtime = "remote_http"
trust_tier = "community"
[host_requirements]
nexara = ">=0.1.0"
example_app = ">=0.2.0"
[policy]
action_class = "read"
scopes = ["read"]
confirmation = "never"
allowed_hosts = ["https://tools.example.com"]
requires_secrets = ["EXAMPLE_API_KEY"]Legacy app-specific compatibility fields are intentionally not part of the
Nexara schema. Host applications can add their own keys under
host_requirements while Nexara keeps the contract reusable.
nexara-server exposes secure-by-default routes for embedded or standalone use:
GET /healthGET /v1/nexara/toolsPOST /v1/nexara/tools/callGET /admin/nexara/skillsPOST /admin/nexara/skills/install
The server owns a default bearer-token middleware and supports development no-auth only when explicitly configured. Host applications with existing auth can call the lower-level runtime and registry contracts directly.
cargo fmt --all -- --check
cargo test --workspaceFor release preparation, see docs/release-validation.md.
Nexara 0.1.0 was the first public library surface. The 0.1.1 line adds the
opt-in one-line policy authoring layer while keeping the standalone crates,
contracts, docs, examples, and tests ready for hosts to embed the runtime or run
the authenticated HTTP server.
