Security

Runtime permissions

Generated tools need explicit runtime boundaries. Astrail permissions keep public and private surfaces separate, require credentials where needed, and return structured denial states instead of silent failures.

Updated Jun 25, 20266 min read

Implementation

Path to ship.

Review each generated tool before making it available to agents.

Keep private endpoints behind bearer auth and provider credentials.

Block disallowed network targets and destructive calls unless reviewed.

Use logs and trace ids to prove whether a call executed or was denied.

Guide

Why permissions matter

Agents are good at intent, not implicit policy. If a runtime boundary is not explicit, the agent may try calls that look reasonable in context but are unsafe for the system.

Permission checks make the boundary observable. A denied call should say why it was denied, whether an upstream request was attempted, and what trace id connects the decision to logs.

Guide

Production defaults

Public MCP surfaces should expose only reviewed public tools. Private calls should require Astrail API keys and provider credentials, and risky actions should stay behind approval or policy gates.

For website-derived tools, block private-network targets and keep browser-backed behavior labeled separately from API-backed execution.

FAQ

Common questions.

What should a denied runtime call return?

It should return a structured permission denial with evidence that no upstream call was made when policy blocked execution.

Are public and private MCP endpoints the same?

No. Public surfaces should be filtered to reviewed public tools, while private endpoints require bearer auth and stronger runtime checks.