How can an AI use company tools without being given the keys to everything?
This demo shows a governed tool-using agent. The model can decide that it needs a capability, but it cannot execute arbitrary code, query arbitrary databases, or reach arbitrary systems. Every requested action must cross an application-controlled authorization and execution boundary.
Imagine an operations copilot helping a team answer routine questions that may require internal inventory data, deterministic calculations, or an approved external reference API. Giving the model unrestricted system access would be convenient—but unsafe. This agent demonstrates delegated authority instead: the model proposes; application code decides what may actually run.
The approved tool belt
Approved arithmetic operations
Arbitrary Python or unrestricted
eval()Item/category inventory search
Arbitrary SQL, writes, or database administration
Structured country lookup
Arbitrary URLs, browsing, or open-ended network access
Who controls what?
- whether a tool appears necessary;
- which approved tool to request;
- how to combine returned results;
- when enough information exists to answer.
- which tools exist at all;
- whether arguments match the approved schema;
- whether execution is authorized;
- tool execution, error normalization, and audit logging.
Try a controlled business request
The answer below is produced only after requested capabilities pass through the application-controlled boundary.
Run a request to produce a business answer.
These are the structured requests, normalized results, and current-run audit records behind the business-facing view.
Security and failure semantics
The demo distinguishes two classes of failure that should not be conflated:
Blocked before execution — the application refuses the model's request because the tool is not registered or the arguments violate the approved schema. The underlying capability never runs.
Approved but execution failed — the requested capability was allowed, but the tool encountered a runtime or dependency error such as division by zero or an external API failure.
Both outcomes are normalized into structured results and written to the current-run audit trail. This is a portfolio demonstration of a narrow trust boundary, not a production-certified sandbox or multi-tenant security platform.
Architecture
User request
↓
LLM proposes an action
↓
Structured ToolCall
↓
Application authorization boundary
├─ blocked → normalized blocked result + audit record
└─ approved
↓
Controlled executor
↓
Approved capability
↓
Normalized ToolResult + audit record
↓
Result returned to model
↓
Additional approved tool request or final answer
The model never receives unrestricted shell, Python, filesystem, SQL, or arbitrary network execution. The reusable primitive is the application-owned capability boundary.