Granting a Tool ≠ Approving Every Action: Three Key Layers of AI Agent Permission Control

Giving an AI Agent access to a tool and approving everything that tool can do are two entirely different things. Cisco President and Chief Product Officer Jeetu Patel made this distinction crystal clear on Episode 67 of the Chain of Thought podcast: you can give an Agent email access to help you book a restaurant, but that doesn't mean it can casually message board members.

The core of this argument breaks down into three parts: action-level authorization, runtime boundary monitoring, and a self-built evaluation system. Miss any one of these, and your Agent goes from "helpful assistant" to "risk."

Tool authorization and action authorization are not the same thing

Tool authorization answers "can this Agent use this integration," while action checking answers "what specifically can it do, and to whom." Patel uses the email scenario to separate the two: with the same email connection, "booking dinner" and "contacting the board" are two completely different actions that require separate approvals.

You can't just do access control on an Agent—you have to do action control. You want to give the Agent permission to send email, permission to access your inbox, but you don't want to give it a blank check. You want it to say: you can go out and help me book a dinner reservation. But what you can't do is contact my board and start randomly messaging them.

— Jeetu Patel, President and Chief Product Officer, Cisco, Chain of Thought Episode 67

In terms of engineering implementation, Patel suggests storing each sensitive decision as a triple of "tool, action, target class." ("inbox", "reserve", "restaurant") and ("inbox", "message", "board") need to go through different approval paths. Any triple that hasn't been pre-approved should be intercepted before the call.

The key is that this allowlist must be enforced outside the model, paired with a set of runtime intent checks. Patel's assessment: Agents are too smart, and static rules will quickly be bypassed. Boundary conditions need to be dynamically computed at runtime based on whether "the current behavior deviates from the original intent," and intercepted as soon as drift occurs.

The "tool, action, target class" triple design is similar in approach to the ABAC (Attribute-Based Access Control) model commonly found in the access control domain. In traditional security systems, RBAC only answers "what interfaces can a role call," while ABAC incorporates resource, action, and environmental attributes into the judgment, enabling fine-grained rules like "a finance role can initiate transfers under ten thousand dollars." In the Agent context, target class is essentially a coarse-grained segmentation of resource attributes. Moving approval granularity from "integration" down to "triple" is fundamentally about treating the Agent as an untrusted caller that could be hijacked by prompt injection.

Another concept that's easy to confuse is the division of labor between "allowlist" and "intent checking." The allowlist handles static interception of known out-of-bounds combinations—it's a whitelist. Intent checking handles catching new exits not covered by the allowlist—it's dynamic anomaly detection. Only by layering both can you address what Patel describes as "Agents being too smart, with static rules getting bypassed."

Action supervision and Token monitoring must be done together

Interception is only the first layer. Patel places Token consumption monitoring at the same monitoring level as system resilience and guardrail violations—meaning the Agent's "economic behavior" should be treated on par with its "behavioral boundaries."

Third, you have to make sure you're monitoring the Token economy, that these Agents aren't over-consuming in their Token usage patterns.

— Jeetu Patel, Chain of Thought Episode 67

Cisco's approach is phased: first give employees loose Token access so everyone gets familiar, then shift to Token rationing like per-head quotas—a team gets a certain number of Tokens, and must deliver corresponding output. The next question Patel raises is architectural: how to improve Token output efficiency by 20% to 60% at the same cost.

In implementation, you can use a single check function to consolidate multiple decision points: first validate parameter legality, then check whether the Agent has already been quarantined, then determine whether this call will push Token usage over budget, and finally compare against the allowed_actions triple. When the Token budget is exceeded, directly mark the Agent as quarantined, blocking all subsequent calls until manually released.

def check_action(agent, tool, action, target_class, tokens_needed):
    if agent.quarantined:
        return "blocked"
    if agent.tokens_used + tokens_needed > agent.token_budget:
        agent.quarantined = True
        return "quarantine"
    key = (tool, action, target_class)
    if key not in agent.allowed_actions:
        return "intercept"
    agent.tokens_used += tokens_needed
    return "allow"

allowed_actions stores the approved triples. Exceeding the Token budget directly triggers quarantine, halting subsequent calls until manual release. At the same time, real-time actions are continuously compared against the task's original intent—any divergence gets intercepted. This is exactly what Patel repeatedly emphasizes: static rules set at deployment time will be circumvented by Agents.

Token budgets and quarantine mechanisms correspond in engineering to two patterns: "circuit breaking" and "rate limiting." Circuit breaking targets anomalies—for example, if a call triggers an out-of-bounds action, the Agent's subsequent capabilities are cut off. Rate limiting targets volume—for example, Token usage rate or total volume exceeding quota. The reason Token overage directly triggers quarantine rather than simply rejecting the current call is that sustained overage often means the task objective itself has deviated from the expected plan, and a single rejection won't stop it from continuing to try.

What Patel refers to as "improving Token output efficiency by 20% to 60% at the same cost" is essentially an inference efficiency optimization problem. Common approaches include prompt compression, cache reuse, routing small tasks to smaller models, and reducing unnecessary tool-calling round trips. The significance of this metric is that Token cost isn't purely a financial issue—in compute-constrained environments, saving Tokens means freeing up inference capacity for other tasks.

Build your own evaluations before routing models

A high score on public leaderboards doesn't mean the model performs well in your scenario. It only means the model does well on the behaviors that leaderboard measures. Patel's recommended order is: first build evaluations around your own tasks, then use the evaluation results to decide whether a prompt should go to a cheap or expensive model.

Your benchmarks and evals won't tell you the full story—this is another thing most people don't realize. A model doing well on one eval doesn't mean it'll do well in your environment. It just means it does well on that specific set of behaviors that eval measures.

— Jeetu Patel, Chain of Thought Episode 67

Patel's definition of "cost" is also worth noting: it's not just the dollar price of Tokens, but also the watts it consumes—a situation where you have money but no power is possible. He mentions that of the total available compute today, 60% is going toward inference. Each task needs to clearly articulate the trade-off across three dimensions: intelligence, cost, and control. For tasks where control matters more (like sensitive data), the last 5% of intelligence may not matter much.

Human approval should be retained until the use case has accumulated a trustworthy track record. Patel's version: keep human approval in place until the model is fine-tuned well enough for your environment, and you have enough statistical samples of its decisions to feel confident—only then consider taking the human out of the loop. This threshold varies by use case, by organization, and by task complexity.

"Model routing" refers to having multiple models at different price points and capability levels in the same system, dispatching each prompt to the most appropriate one based on task type, sensitivity, and budget. Routing decisions depend on two signals: the importance of the task, and the task's historical performance on candidate models. Public leaderboards can't provide the latter because they measure general capabilities, while your task distribution is a specific narrow domain.

Patel's emphasis on the "intelligence, cost, control" three-dimensional trade-off corresponds to layering in evaluation set design. The intelligence dimension can be measured by accuracy and completion rate; the cost dimension includes Token price and power consumption; the control dimension looks at whether the model consistently obeys constraints on sensitive operations and whether it's easily induced to go out of bounds. For sensitive data tasks, the control weight should be increased, and even choosing a cheaper model at the cost of some intelligence may be worthwhile. The retention period for human approval is essentially waiting for the evaluation sample size to reach statistical significance, so decisions no longer rely on intuitive trust in the model.

Frequently Asked Questions

If I connect email to an Agent, can it just send messages freely? Connecting is just tool authorization. Patel treats booking dinner and contacting the board separately—these two actions on the same inbox require their own action checks.

Can public benchmarks tell me which model to route to? They report how the model performs on that eval's behaviors. Patel believes this doesn't prove how it'll perform in your environment. Build evals for your use case first, then route.

What should I do if an Agent burns Tokens or goes out of bounds? Intercept the out-of-bounds action. If Token usage is over-consuming, quarantine the Agent and let it "cool off."

Key Takeaways

• Key sensitive calls by "tool, action, target class," and intercept any unapproved combination.
• Set a Token budget for each Agent, and quarantine on overage.
• Recompute boundary checks at runtime against the original intent, and enforce authorization outside the model.
• Before routing prompts between cheap and expensive models, build evals on your own use cases.
• Keep human approval in place until the use case accumulates a trustworthy track record.

The full conversation (with transcript) is available on Chain of Thought Episode 67.

One-line Summary

Cisco executive Patel advocates constraining AI Agents with action-level authorization, runtime boundary monitoring, and self-built evaluations.

Paragraph Summary

The article distills Cisco President and Chief Product Officer Jeetu Patel's views from Chain of Thought Episode 67, with the core being to break AI Agent governance into three layers. The first layer is action-level authorization: connecting a tool doesn't mean approving everything it can do—on the same email integration, "booking a restaurant" and "contacting the board" need different approvals, implemented in engineering as "tool, action, target class" triples enforced outside the model. The second layer is runtime monitoring: placing Token consumption and guardrail violations at the same monitoring level, quarantining Agents on budget overage, and dynamically recomputing boundaries against the original intent. The third layer is building evaluations before deciding prompt routing: high public leaderboard scores don't guarantee performance in your environment, cost must account for both dollars and watts, and human approval should be retained until the use case accumulates a trustworthy statistical record.