How we control which tools an AI agent is allowed to use
Ask Titan discovers capabilities through MCP, resolves application policy for the current user, and binds only the permitted tool set to the orchestrator model. Discovery and authorization remain separate concerns.
Everything currently exposed through MCP
Only permitted schemas are bound
The engineering problem
Tool discovery is not authorization
An MCP client can discover a catalog of capabilities. That catalog answers a technical question: what tools does this capability service expose? It does not answer the application question Ask Titan still has to resolve: which of those tools should this user be able to place in front of the model?
We keep that decision in application code. The model is allowed to choose among a permitted set. It is not asked to decide which capabilities it is permitted to use.
Discovery
What exists?
Load the current capability catalog and tool schemas exposed through MCP.
Authorization
What is permitted?
Resolve policy for the validated identity and calculate the effective tool set in application code.
Model binding
What can the model choose?
Bind only the effective tool schemas so unavailable capabilities never become normal choices for that model call.
One request through the boundary
Resolve access before the model sees a tool schema
Ask Titan validates the request identity, discovers the current MCP capability catalog and resolves the configured capability grants. The runtime policy resolver calculates the effective tool set before the orchestrator is built and any tool schemas are bound to the model.
Step 1 · calculate the effective set
Authorization is an intersection. Not a prompt instruction
Ask Titan resolves tool access from application policy and compares those grants with the tools currently available through MCP. A grant alone is not enough if the capability no longer exists. Discovery alone is not enough if the current identity is not permitted to use it.
Start from validated identity
Resolve policy only after the application has a trusted identity for the request.
Load application grants
Use stable capability identifiers to determine the tools permitted for that identity, including any explicit baseline policy.
Intersect with discovery
Only tools that are both currently discoverable and permitted become part of the effective set.
available_tools = await discover_mcp_tools()
user_grants = await resolve_policy(identity)
allowed_names = unique([
*user_grants,
*baseline_capabilities,
])
effective_tools = [
tool
for tool in available_tools
if tool.name in allowed_names
]| Discovered | Granted by policy | Effective result |
|---|---|---|
| Yes | Yes | Bind the tool |
| Yes | No | Exclude it |
| No | Yes | Unavailable; do not bind |
Step 2 · bind the model
Do not show the model tools it should not use
Tool calling works from schemas supplied to the model. In Ask Titan, the orchestrator graph is created with the effective tool set and the same set is bound to the model. A disallowed capability is therefore not a normal candidate for model selection in that request.
What the model receives
A deliberately reduced capability surface
Permitted capability schema
Name, description and input schema are available for model tool selection.
Unauthorized capability
The schema is excluded from the current model call rather than relying on the model to ignore it.
orchestrator = build_graph(
tools=effective_tools,
checkpointer=conversation_memory,
)
# Inside the model node
model_with_tools = (
model.bind_tools(effective_tools)
if effective_tools
else model
)
response = await model_with_tools.ainvoke(context)Prompting is not authorization
“Do not use this tool” is behavioral guidance
Once a tool schema is bound to the model, that capability is part of the model's available decision surface. A prompt can influence whether the model chooses it, but it does not remove the capability. Ask Titan resolves authorization in software first and binds only the effective tool set to the model.
Bind every tool, then rely on prompt instructions
The model sees capability schemas outside the effective tool set and can emit tool calls for them. If the prompt is the only restriction, enforcement depends on probabilistic model behavior.
Resolve access first, then bind only the effective tool set
Runtime policy intersects discovered capabilities with configured grants before model binding. The model can reason only over permitted capabilities, while source-level authorization remains enforced during execution.
MCP boundary
MCP authorization and application tool policy solve different problems
Modern MCP specifications include authorization mechanisms for protecting client-to-server access. That is important, but it is not the same question as Ask Titan's application policy: which discovered capability schemas should be exposed to the orchestrator for this validated user?
We keep those concerns separate so protocol-level access can evolve without moving per-user capability policy into the model or conflating it with source permissions.
MCP transport / server access
Controls whether a client can authenticate to and communicate with the MCP service.
Application capability policy
Controls which discovered tool schemas become eligible for the current Ask Titan request.
Model tool selection
Chooses among the already-permitted schemas presented to the model.
Source authorization
Controls what the underlying system allows the selected capability to read or execute.
Separate security layers
Tool authorization does not grant access to the data source
Allowing a user to invoke a specialist capability and allowing that capability to access data are separate controls. Ask Titan treats application-level tool authorization as one layer, not as a replacement for credentials, roles, grants or source-native controls in connected systems.
Layer 1
Capability authorization
May this identity use this Ask Titan capability at all?
Layer 2
Capability connection
Which configured source or semantic model does the specialist execute against?
Layer 3
Source enforcement
What do the credentials, roles, grants and source-native security controls actually permit?
Important: this architecture does not imply automatic end-to-end row-level or column-level security. Those controls depend on the connected source, identity model and deployment configuration.
Capability lifecycle
Policy has to survive a changing tool catalog
Enterprise tool catalogs change. Capabilities are added, renamed, disabled or removed. Authorization therefore cannot be a one-time list copied into a prompt. The effective set has to be recalculated against the current catalog.
Discovered, not granted
A newly exposed capability does not automatically become available to existing users.
Granted, not discovered
A stale policy entry cannot create a capability that is no longer in the current catalog.
Discovered and granted
Only the intersection becomes part of the orchestrator's effective tool surface.
Failure cases
Authorization should fail by reducing access
The useful property of the intersection model is that most mismatches reduce the effective tool set. A stale grant, a missing capability or malformed user-specific policy should not silently turn into broader model access.
| Case | Expected runtime behavior |
|---|---|
| Request identity cannot be validated | Do not resolve a normal user tool set for the request. |
| User-specific policy is absent or malformed | Do not expand access beyond explicitly defined baseline policy. |
| Tool is discovered but not granted | Exclude the tool before graph construction and model binding. |
| Policy grants a tool that is not discovered | The tool is unavailable and cannot enter the effective set. |
| Underlying source rejects execution | Respect the source boundary; application tool access does not override source security. |
Discovery ≠ authorization
Knowing a tool exists does not make it available to the current user.
Prompting ≠ authorization
Model instructions are not the place to enforce the effective capability set.
Tool access ≠ data access
Application grants do not replace source credentials, roles or native security.
Policy grant ≠ tool existence
Stale grants cannot resurrect a capability missing from the current catalog.
Engineering takeaway
The model should choose among permissions. It should not define them
Ask Titan keeps capability policy in deterministic application code and gives the model only the effective tool set. That keeps model reasoning inside a capability boundary the application can inspect, change and test independently.
Patterns we keep
Next in the series
Part 4 · How Ask Titan queries Power BI semantic models with DAX
Next we go behind one specialist capability boundary: semantic-model metadata, measures and relationships, DAX generation, execution and error feedback when governed business logic lives in Power BI.
Read Part 4FAQ
Enterprise AI agent tool authorization questions
Practical answers about MCP tool discovery, application-level capability policy, model tool binding and source authorization.
What does tool authorization mean in Ask Titan?
Tool authorization determines which discovered specialist capabilities are permitted for the validated identity and can therefore be bound to the orchestrator model for the request.
Why is MCP tool discovery not the same as user authorization?
MCP discovery tells the client which tools the capability service currently exposes. Ask Titan still applies application policy to decide which of those discovered tools become available to the current user and model call.
Does MCP have its own authorization?
Yes. Current MCP specifications include authorization mechanisms for protecting client-to-server access. Ask Titan's application tool policy is a separate layer that decides which discovered capability schemas are exposed to the orchestrator for a particular validated user.
Why filter tools before model binding?
Tool schemas supplied during model binding define the capabilities the model can normally select. Filtering first means unauthorized capabilities are excluded from the model's effective tool surface rather than relying on prompt instructions to suppress them.
Can a system prompt be used to restrict tool access?
A prompt can guide model behavior, but it should not be the primary authorization boundary. Ask Titan resolves capability access in application code and binds only the effective tool set to the model.
What happens if policy grants a tool that is no longer available?
The tool does not enter the effective set because Ask Titan intersects policy grants with the currently discovered MCP catalog. A stale grant cannot make a missing capability callable.
Does application-level tool authorization replace data-source permissions?
No. Capability authorization and source authorization are separate. Credentials, roles, grants and source-native controls still determine what the connected system actually permits.
Can the model call a tool that was not bound to it?
The normal tool-calling surface contains only the schemas bound for that request, and the LangGraph tool node is built from that permitted set. An excluded capability is therefore outside the configured tool set for the turn.
How do tool permissions change when the capability catalog changes?
The effective tool set is recalculated against the current catalog. New tools do not automatically inherit existing grants, while removed tools no longer become effective even if a stale policy entry remains.
Enterprise AI authorization
Give AI agents useful tools without making every tool available to every user
Ask Titan separates capability discovery, application policy, model tool selection and source authorization. The same pattern can be used in enterprise AI systems that need controlled access to multiple specialist capabilities.
One request, four decisions
Technical references
The examples in this article are simplified architecture patterns. These public references document MCP authorization direction and the LangChain/LangGraph tool-binding behavior used in the design.