Transport and authorization
Aevah publishes platform capabilities as versioned, permission-scoped tools that enterprise agents discover and call over MCP.
- Streamable HTTP — Production: Remote connections use Streamable HTTP with OAuth 2.1 bearer authorization.
- stdio — Production: Available only for local development against a development tenant.
- Legacy HTTP+SSE — Not Available: Not available. Aevah uses Streamable HTTP for remote MCP connections.
Tenant endpoint discovery
Each licensed customer receives an administrator-issued MCP connection for its own Aevah instance. The exact endpoint and discovery metadata are available only inside the authorized environment. They are not listed publicly, shared across customers, or exposed through a guessable directory.
MCP primitives
- Tools — Production: The primary surface. Every Aevah capability reaches agents as a tool.
- Resources — Production: Read-only governed artifacts, including audit records, proposals, and version history, addressed by stable URI.
- Prompts — Production: Curated task templates for common stewardship and discovery flows.
- Notifications — Production: Tool-list changes and progress for long-running operations.
- Sampling — Not Available: Not available by design. Aevah does not request inference from the connecting client; model access inside Aevah is separately governed and administrator-granted.
- Elicitation — Not Available: Not available by design. Consequential actions return a proposal for human approval or require explicit prior confirmation.
Tool catalog and discovery
The public website describes tool classes and families rather than publishing the complete catalog. Inside an authorized connection, the permission-filtered tool list is the source of truth for the capabilities available to that caller.
tools/list is filtered to the caller's effective permissions. Unauthorized tools do not appear. Catalogs can differ between callers and change when access changes. Clients refresh the catalog on connection and after a tool-list-changed notification; they do not cache a catalog across identities or sessions.
Read and write classifications
An agent cannot promote itself between read, proposal, and write classifications, and no tool bypasses the approval path governing the same action in the user interface.
- read: Returns data and changes nothing. It executes directly under the caller's permissions.
- propose: Produces a change proposal a human must approve. It changes nothing on its own.
- execute: Performs a governed change under explicit prior confirmation. Permissions are reauthorized at execution.
Delegated identity and least privilege
An Aevah-connected agent acts with the identity of the person who triggered it. It cannot acquire broader access merely because it is an agent. Every tool call is checked against that identity, tenant, permission scope, resource policy, and requested action.
If the triggering person cannot read a resource or perform an action directly, the agent cannot do so on that person's behalf.
Tool versions and compatibility
Breaking changes publish a new tool version; existing versions are never altered. Deprecation is signalled in tool metadata with a replacement pointer.
A breaking change removes or renames a field, narrows an accepted input, changes a field's type or meaning, or adds a required input.
Classification and audit
Every MCP call is authorized, classified, and audited, including failed calls.
Audit records do not contain argument values, returned payloads, or field-level customer data. They record that a call occurred, by whom, under what authority, and to what effect. Customers can retrieve their audit records through the platform and as an MCP resource.
- Correlation ID
- Timestamp
- Principal and authorization mode
- Tool name and version
- Permission exercised
- Read/write classification
- Outcome
- Error code when applicable
- Count of records affected
- Approval reference when applicable
Immutable record history
Governed changes are immutable and cumulative. A change creates a new record version; nothing is overwritten or erased. Prior versions remain retrievable, any two versions can be compared field by field, and every version is attributable to a principal and tool call. Reverting is a forward operation that supersedes the current version with a new version carrying earlier values, preserving the complete change history.
Execution, retries, and cancellation
Mutating calls accept an idempotency key. Repeating a call with the same key inside the configured deduplication window returns the original result. Errors are classified as retryable or terminal. Long-running work becomes a tracked operation with progress notifications and a status resource. Cancellation stops further work without partially applying a governed change. A call applies fully or not at all; multi-record operations also return per-record outcomes.
Reference examples
The GA developer reference includes synthetic read and governed-change examples. The read example covers catalog search, filtered results, and a response envelope with tool version and correlation ID. The governed-change example follows proposal creation, steward approval, confirmed execution, the resulting record version, and its audit record.
Public discovery boundary
Aevah provides MCP discovery metadata within licensed customer environments. Its exact location and contents are not disclosed on the public website. Capability discovery occurs after an administrator supplies an authorized, per-instance connection. A focused public summary is available at /mcp.md.