AI Agent Tool-Call Guardrails: Controlling What Agents Actually Do

A hallucinating agent is an embarrassing agent. If an agent hallucinates a tool call, an email is sent, the row is deleted, or the refund is approved. This disconnect between words and actions is the reason that AI agent tool call guardrails have emerged as a thing in and of themselves within AI security, apart from the prompt filters and output classifiers that most teams developed prior to them. A prompt-level guardrail can stop a human from pressing enter with a harmful response, but might not be able to prevent an agent from calling three potentially legal tools in a row, as the text will arrive at an output filter after the action has already been executed. This is a working guide for engineers developing or assessing that missing layer: What tool-call guards intercept, what policy categories are relevant, where to place the guards, and how to demonstrate guard placement.

What Are Tool-Call Guardrails?

Imagine that you have a support agent configured with three behaviors: search_customer, issue_refund, and send_email. The layer that determines whether or not a certain call of issue_refund, with these certain arguments, in this certain session, will execute or not execute is a tool-call guardrail. It has nothing to do with whether the agent's chat response is polite or on brand. A decision to take an action, taken against a policy, at the time the action is about to occur.

Because the literal function calling term, like in the older model provider days, is being used for what is now referred to as "tool calling" by agent frameworks, and is now the term used when talking about what happens when a tool is called by an agent, it is sometimes referred to as "function calling" guardrails instead. As the pattern gained in popularity from one API call in one model provider's SDK to any arbitrary external tool that could be called through a standard protocol, this name changed. The problem was the same: a model generates a structured request to perform some action in the real world, and something has to validate the request before execution.

This distinction is increasingly made explicit in the documentation of the frameworks. For example, LangChain's newer middleware system separates out before_model and after_model hooks (the ones that touch the language layer) from wrap_tool_call hooks (the ones that touch the action layer), as a team that just validates the prompts and outputs is only validating the part of the pipeline that it is most likely to be able to fix.

Tool-Call Guardrails vs. Prompt/Output Guardrails

Agent guardrails control an agent's activity and not merely what it says, according to research from Obsidian Security. Prompt and output guardrails filter the text to and from a model, while tool-call guardrails add allowlists, parameter validation, least-privilege scopes, and human-approval gates, which account for the fact that an agent may call an API and pass data through without a human reading a transcript in between.

Two layers capture two different failure points on the same request. An input guardrail may pass through if it lacks any profanity and no apparent jailbreak phrasing. A tool-call guardrail is looking at the same interaction downstream and notices that the agent is trying to run a query against the production customer database, rather than the read replica that it was scoped to use. Both layers are not an alternative for each other.

Why Prompt Filtering Alone Can't Stop Unsafe Tool Use

So the reason this gap is important is the scale and autonomy. According to International Data Corporation, there will be approximately 28.6 million active AI agents in enterprises by 2025, reaching over 2.2 billion by 2030, and OWASP's Top 10 for Agentic Applications, which was developed in December 2025 and peer-reviewed by contributors from NIST, Microsoft's AI Red Team, and AWS, identifies agent goal hijack as the leading risk category. Both of those facts have to do with the things agents say.

Agents Chain API Calls Without a Human in the Loop

If a chatbot gives back a wrong answer, it's a problem of wording that a human can pass. When an agent acts on poor judgment, it's already made a change. Once a model can query a database, it can hit an internal API, run code, or post to a channel; a hallucinated argument or an injected instruction ceases to be a content-quality problem and becomes an executed action.

Let's say you have a support agent that has the permissions list_orders, issue_refund, and send_email, and you want to do things efficiently. One instruction injected into the incoming ticket, a text like any other from a customer to a prompt filter, can take the agent through all three tools one after the other, before somebody has a chance to read the transcript. They are normal tool use each call, individually. The attack is the chain, and a filter that only looks at the prompt or the final response never looks at the chain.

Static Permissions Are Blind to Context

The majority of agent identities today are scoped at one time, when the token is issued, or the service account is created, and that scope remains until someone modifies it on the fly. The resulting gap is described straightforwardly by Sweet Security's research on agent runtime security: ‘The system can only enforce the authorization when the agent is given the token, but it has no indication of what the agent is actually doing when it uses it. There is no way for a static role to distinguish the two from each other, and the same call to wire_transfer might be mundane in one workflow, but a compromise signal in the other.

The comparison of access-control models at Obsidian is similar but put in a different light. Role-based access control works well for an evergreen hierarchy of organizations, but is, in its own lexicon, too rigid for a dynamic AI workflow; those who said it was more suited for dynamic AI workflows are precisely those who said attribute- and policy-based models that assess the user, the resource, and the environment at the same time are better fit for such dynamic workflows, and they are.

Where Tool-Call Guardrails Intercept Agent Behavior

The guardrail architecture proposed by Microsoft Foundry identifies four locations the control might be placed: At user input, at tool call, at tool response, and at final output. The middle two are the ones prompt-and-output thinking more often overlook, and each contributes about 50-100 milliseconds of processing time, according to Microsoft's own documentation- a pretty good price to pay for catching something that a text filter structurally can't see.

Before the Call, Pre-Execution Policy Evaluation

This is the most basic form of pre-execution policy enforcement for AI agents; the decision takes place before the tool runs rather than after a log review. A 2026 paper entitled deterministic pre-action authorization presents a reference system called Open Agent Passport, which intercepts calls to each tool synchronously, applies a declarative policy to the call, and generates an auditable record that is cryptographically signed, taking a median of 53 milliseconds to enforce over a body of 1000 calls.

It's the paper's adversarial testbed number that's more interesting. When the agent used model alignment alone, social engineering against the agent succeeded 74.6% of the time (out of 1,151 live sessions and 4,437 authorization decisions), and a bounty was offered for successful attacks. With the pre-action authorization gate that was applied in a restrictive manner, the same attacks were successful 0 times in 879 attempts. There was no change in the model between the two conditions. The only difference was a gate evaluating the call before it ran.

This is beginning to become a first-class hook through frameworks instead of being something teams force onto it. CrewAI includes an open pull request to add crew-level before_tool_call and after_tool_call callbacks that raise an exception to prevent a call from taking place; the exception text will be returned to the agent as the tool result. Here is a small version:

def before_tool_call(agent, tool_name, tool_input):
if tool_name == "wire_transfer" and tool_input.get("amount", 0) > 10000:
raise PermissionError("wire_transfer over $10,000 requires approval")
crew = Crew(agents=[finance_agent], before_tool_call=before_tool_call)

def before_tool_call(agent, tool_name, tool_input):
if tool_name == "wire_transfer" and tool_input.get("amount", 0) > 10000:
raise PermissionError("wire_transfer over $10,000 requires approval")
crew = Crew(agents=[finance_agent], before_tool_call=before_tool_call)

def before_tool_call(agent, tool_name, tool_input):
if tool_name == "wire_transfer" and tool_input.get("amount", 0) > 10000:
raise PermissionError("wire_transfer over $10,000 requires approval")
crew = Crew(agents=[finance_agent], before_tool_call=before_tool_call)

LangChain's equivalent is a wrap_tool_call middleware hook, and both operate at the framework level, not within the model's own output parsing, meaning that if a prompt succeeds in getting the model to request a blocked call, it still has to pass the hook to get executed at the framework level.

The Call Itself, Parameter and Schema Validation

Before sophisticated attacks, production agents go out of the ordinary in mundane ways. The open-source project callguard, directly designed to strengthen tool calls, lists six frequent failure classes that it can handle in one decorator: JSON with single quotes or trailing commas because of imperfect model output, wrong argument types like a stringified "123" when an integer is expected, missing required arguments because the model simply forgot to include them, typo'd tool names like send_emial instead of send_email, uncapped spend because of runaway loops, and retry storms against a tool that returns server errors.

The first four are caught by schema validation, which acts as a guardrail. A call that comes in with an argument that is malformed or out of range is rejected at the border:

{
"tool": "issue_refund",
"arguments": { "order_id": "ORD-4471", "amount": "not_a_number" },
"validation_result": "REJECTED",
"reason": "amount must be numeric and <= order total"
}

{
"tool": "issue_refund",
"arguments": { "order_id": "ORD-4471", "amount": "not_a_number" },
"validation_result": "REJECTED",
"reason": "amount must be numeric and <= order total"
}

{
"tool": "issue_refund",
"arguments": { "order_id": "ORD-4471", "amount": "not_a_number" },
"validation_result": "REJECTED",
"reason": "amount must be numeric and <= order total"
}

One beneficial modification of this is assigning trust levels to arguments depending on where they originate from. An argument that the user types directly into the system should indeed be trusted more than an argument that the agent only reads in a document, e-mail or web page, as the latter is an indirect route and tricks the agent into following the instructions in the message rather than the one in the argument.

After the Call, Tool Response Inspection

Microsoft's fourth intervention point – tool response – is the point that is generally overlooked in discussions about guards, and the one that is the most important for an MCP-specific attack. The bottom line in OWASP's explanation of MCP tool poisoning is right on the money: The tool description is checked once at connection time, but tool responses are passed directly to the context of the model on each subsequent call without a similar check. If the attacker has control over a tool's output, then instructions can be inserted into the output of such a tool that the agent will consider the instructions trusted context when it receives the output of the tool.

A post-execution hook then fills that gap, scanning the answer that comes back from a tool before it reaches the model: looking for embedded instructions, redacting secrets or PII that have sneaked into the answer, and highlighting data patterns being sent out that are suspicious of being exfiltrated rather than a normal answer. According to Microsoft's own documentation, a team building a custom tool needs to be prepared to have to deal with the limitations of the tool's coverage points because tool call and tool response intervention points currently require moderation support by the tool itself, which limits the coverage to a specific list of connectors, including Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, and Bing Grounding.

Core Policy Categories for Tool-Call Guardrails

Remove the names of the various vendors, and the majority of the tool-call guardrail systems have a few identical policy expressions. They are all gathered into seven buckets enforced per virtual key, per team, and per environment by the open-source AI gateway Bifrost, which is just as good a list as any of the things a policy engine must be able to enforce.

Tool Allowlists and Denylists

The cleanest control is structural, i.e., an agent which has a scope of read_ticket, search_kb, and draft_reply shouldn't have access to delete_ticket, and that's not because the rule blocks its call now, but rather because it wasn't registered for that identity in the first place. OWASP's MCP Top 10 highlights the failure mode that this prevents: MCP servers' permissions are often set too broadly or loosely, and if they are misused by a user with poor scope enforcement, it can allow the attacker to execute various unauthorized actions such as altering the repository or exfiltrating your data.

Parameter Validation (type checking, schema enforcement, malformed args)

In addition to type and format checks outlined earlier, there are destination and recipient field rules, too, that are enforced. A send_email tool may have full permissions to an agent, but a policy could still limit the domain(s) that are allowed to be sent to, or limit the attachment sizes, in the to field, as a parameter and not rely on the tool-level allowlist to cover all content sent from the call.

Dynamic, Context-Aware Authorization (identity, task, resource, live behavior)

This is what the research literature refers to as call-by-call authorization, in which you consider the authorization of a call with regard to the tool, the data, and the call time – as opposed to checking a role once and trusting it for the rest of the session. The architecture is Sweet Security continuously watching, comparing to a baseline, determining if it's a deviation, and enforcing the decision as you log into the application, as opposed to a permissions table checked at login time.

Budget and Cost Caps (preventing runaway spend loops)

One of the two problems that each agent framework reinvents and gets wrong is "$40 runaway loops because nothing capped spend," according to the 'callguard' project's description of its purpose. If no one adds a budget cap policy, it is easy to overlook:

guardrails:
behavior:
cost_limit: 5.00
cost_per_call: 0.02
on_exceed: block_and_alert

guardrails:
behavior:
cost_limit: 5.00
cost_per_call: 0.02
on_exceed: block_and_alert

guardrails:
behavior:
cost_limit: 5.00
cost_per_call: 0.02
on_exceed: block_and_alert

Rate Limits and Iteration Caps

There are two different problems that are solved by cost caps and iteration caps. An agent that is called a hundred times a minute, over and over by a search tool which fails to return a result that meets its stopping condition is not a horrendous cost per call, but over time is a runaway process, one which a rate limit would detect sooner than a budget threshold would.

Destination Restrictions (where tool outputs are allowed to go)

You don't get authorization to call a tool; you don't get authorization to send anything anywhere from the tool. Similarly, an agent with read access to a customer record should not be able to forward the contents of that record to another webhook or copy/paste the contents of that record into a public code snippet—just because technically a downstream tool call was within scope. In the case of the MCP tool call guardrailing, this control becomes more important due to the fact that a call result could initiate another call to the outside. More than 7,000 MCP servers were analyzed by BlueRock Security, and it was found that 36.7% were potentially vulnerable to server-side request forgery, a failure the destination allowlist was designed to prevent: in this case, an attacker could instruct the server to send requests to internal resources on the agent's behalf.

Human-in-the-Loop Escalation for High-Impact Actions

The most frequent case of losing this control is to use it for all things, creating an approval queue that no one can keep track of, and eventually turning it off. From the enterprise point of view, badly placed, model-aware, approval gates that need human judgment for each model output are used in production for a short period and then get forgotten, whereas gates that are scoped to a consequential action, that write to a system of record, that move data across a boundary, or that grant access, are rarely noticed and tend to survive.

Static vs. Dynamic Authorization

This difference, which pervades all the groups above, would seem to merit a special mention, for it is the one most important architectural decision a team will make in constructing this layer.

Static permissions are not incorrect; they are insufficient. No one should begin an agent with standing administrative access, and a properly "reserved" role is still a good starting point. The issue here is that a properly scoped credential issued at 9 a.m. can be mistrusted by corrupted or tampered agents at 9:05 a.m. before anyone in a static grant can detect it. Dynamic authorization is the layer that monitors the call itself, not only the documentation that granted the identity to produce the call.

Where Tool-Call Guardrails Should Be Enforced

There are two locations in the stack where this logic could be deployed today, and most mature deployments use both, instead of either one or the other.

In-Framework (decorators, SDK-level hooks like before_tool_call)

Hooks such as CrewAI's before_tool_call or LangChain's wrap_tool_call middleware are executed within the agent process and have full access to the agent's role, current task, and position in a multi-agent chain. It is easy to write fine-grained decisions, but it has to be implemented and maintained in every framework that a team uses, and the hook is as reliable as the code path that calls it.

At the Gateway Layer

The opposing thesis, one that was explicitly advanced by the Bifrost gateway team, is that a gateway observes all requests made by the agent, can't be circumvented by the agent's code, and enforces a single policy for all models and all tools that the agent can access - no matter the code framework they were built with. For MCP traffic, in particular, this idea is realized by Akto's MCP Gateway, which resolves to a single endpoint for every connected server, and authenticates, allows or denies tools for every server, and enforces rate limits for every server without having to make any changes to the servers themselves. It is important that it is centralized enforcement; otherwise, it is not what is actually being practiced on a per-server basis. The unique analysis of the implementations of the MCP that Akto has conducted identified a total of 82% of servers to be vulnerable to path traversal and only 8.5% of all servers in the official MCP registry to implement OAuth, while the remaining 91% relied on static API keys or, shockingly, no authentication whatsoever; this is exactly what a gateway is supposed to mitigate and overcome, not rely on.

Trade-offs Between the Two

Gateways know everything that actually left the process; in-framework hooks know what the agent is trying to do. A code path may be skipped because of a lack of an enclosing hook. A gateway cannot see an in-process function call that does not cross the network. Running framework-aware checks under a gateway for coverage is not the same as running the same checks in both places, but rather filling the gap that is unique to each layer.

Auditability, Proving Enforcement Happened

A document that no one can prove is fired is a policy, not a control. This is the section of the stack on which compliance teams and incident responders ask questions, typically following an incident.

Signed Audit Logs for Every Decision

The pre-action authorization research mentioned above outlines two requirements that can be directly adopted: Authorization decisions need to generate a tamper-evident audit trail, and when no decision is found, the tool call must be denied, instead of being allowed to proceed. Related work on off-host agent authority extends further to signed, hash-chained audit records per decision, meaning that the audit record can't be drastically altered after the fact without breaking the chain. At a minimum, every entry should include the agent's name, the tools and arguments that were requested, the policy evaluated, the result of the evaluation (the verdict), and a timestamp, as an investigator would need to know not only what happened but why it was allowed to happen.

Mapping Enforcement to Compliance Frameworks

This logging isn't relevant to an auditor unless it is tied to a framework that they know. All SOC 2, HIPAA, and GDPR reviews require some variant of the same answer: Does there exist a control? Can you demonstrate a control in production or explain a control in a policy document?

Common Failure Modes Without Tool-Call Guardrails

Throughout this piece, three patterns emerge in incidents and postmortems that happen over and over again, and none of them involve a sophisticated attacker.

Runaway Loops and Cost Overruns

Next, the scenario could hardly be more pedestrian: a tool call returns a result that doesn't meet its stopping criterion, and the agent recursively calls the same tool or a more expensive one until a bill is noticed. The difference between a $5 mistake and a $500 mistake is a hard IterationLimitError or CostLimitError that is raised when those thresholds are crossed. That's why the open-source project agentvoy-guard was born.

Typo'd or Malformed Tool Calls Executing Anyway

Models don't always return a well-structured output, and an implementation of a tool that assumes its input will gladly try to process 123 as a customer ID or even quietly handle an empty required field without the call failing. The six failure classes reported by the callguard project cannot be considered edge cases. The six failure classes reported by the callguard project are not edge cases. They are what occurs in case of a default run of an agent against a tool with no validation layer in front of it.

Agents Reaching Tools or Data Outside Their Intended Scope

In June 2026, Microsoft's security research team documented a specific pattern, mapped to the OWASP tool misuse and agentic supply chain risk categories: a financial operations team created a Copilot Studio agent that was connected to a Dataverse MCP server that contained the approved vendor master, as well as an Outlook connector. An attacker altered the description of a tool on MCP's server without user knowledge. The agent re-trusted the modified tool without asking for re-approval and executed the tool while exporting data out the entire time as an approved call from the outside. No single clearly malicious action; four stages.

A similar scenario is the confused deputy scenario: an MCP server invokes a request on its own elevated privileges, not that of the user requesting the request. An agent executes a query for a user who doesn't have database admin rights and sends it to another user with the admin rights who is connected to an MCP server that executes the query per the agent's request, without verifying whether the original queryer should have been allowed to request it.

How Akto Implements Tool-Call Guardrails

Each of the gaps mentioned above corresponds to a specific aspect of the construction of Akto's agentic security platform.

Discovery of Every Tool an Agent Can Reach

It is not possible to create a scope policy for a tool that is not known. With over 80 connectors, Akto automatically finds and catalogs MCP servers, AI agents, tools, and resources on infrastructure, cloud, and employee laptops, mapping which agents are calling which tools and which downstream servers are being accessed by them. That inventory is what helps put "we think our agents are scoped correctly" into perspective for a security team.

Pre-Execution Policy Enforcement Across MCP and Function Calls

With Akto's guardrail engine, teams can create rule-based and AI-based policies that govern access to tools and sensitive data, which are enforced in real time and not evaluated afterward in logs that nobody reads on time. With respect to MCP traffic, the Akto MCP Gateway is placed in front of the existing servers, without any code changes, and every client-to-server call is funneled through a single point which uses per-call authorization and an MCP registry allowlist as first-class policy objects, not an afterthought tacked onto individual servers.

Continuous Testing Against Tool Misuse Patterns

Static policy quickly becomes stale due to the emergence of new bypass techniques. In total, Akto sends its findings to the guardrail policies and has more than a thousand automated probes that simulate prompt injection, tool poisoning, and unsafe tool-chaining across all agents and MCP servers, and feeds them back into the guardrail policies and runs within CI/CD to prevent the addition of a new tool without an attached policy.

Final Thoughts on AI Agent Tool-Call Guardrails

The first line of defense put in place by most teams was prompt and output filters, but that still does not prevent an agent from taking action based on a bad decision. The most important control is one that checks the tool itself as it is being called, before it is executed, and has a signed log of why it was allowed or not: allowlisted tools, validated parameters, authorization that takes into account context as well as a fixed role, and a check on where results are allowed to go.

Every piece is addressed directly: discovery across 80+ connectors: No shadow MCP server goes ungoverned; pre-execution policy enforcement via its guardrail engine & MCP Gateway: scope is checked at call; continuous red teaming with 1,000+ probes: policies always stay ahead of new misuse techniques.

See how this works against your own agents and MCP servers. Book an Agentic Security demo.

FAQs on AI Agent Tool-Call Guardrails

What are AI agent tool-call guardrails?

These are the policy checks that determine whether a particular tool call with specific arguments provided by a specific agent identity can be allowed to be executed. They are used at the action level of an agent's pipeline, independent of the filters that analyze the prompts and generated text.

How are tool-call guardrails different from prompt or output guardrails?

Prompt and output guardrails filter the language that is sent to and received from a model. Once the agent chooses to call a tool, tool-call guardrails help control what it can do, including allowlists, parameter validation, authorization, and allowable flow of results.

Why can't prompt filtering alone prevent unsafe tool use?

The individual looking actions may be harmless, but an agent can put together a series of such actions, and by the time a response comes to an output filter, the underlying action has already been executed. Research on pre-action authorization was able to achieve 74.6% success using only social engineering and 0% success when calls went through a pre-execution authorization gate.

What is the difference between static and dynamic authorization for tool calls?

Static authorization is done once, at the time of issue of a token, and stays until it is manually altered. Dynamic authorization re-evaluates identity, task, resource sensitivity, and recent behavior on every call, and the same credential might be denied in a context where a static role would have granted it.

What happens before, during, and after a guarded tool call?

A policy engine determines the action to be taken before the call. The arguments are verified during the call with respect to the tool's schema, to ensure that they have the correct type, format, and completeness. Following a call, the call's output is checked for injected code, information leakage, or data exfiltration before the tool ingests it.

What policy categories should tool-call guardrails cover?

Baseline: tool allowlists and denylists, parameter and schema validation, dynamic authorization depending on the context, budget and cost limits, rate and iteration limits, destination restrictions on tool outputs, and human-in-the-loop escalation for high-impact actions.

How do budget or cost caps prevent runaway agent behavior?

By setting a cost limit, you can prevent an agent from executing until it reaches a predetermined amount within a session or time period, thus preventing a common problem of an agent running a tool call and spending a lot of money before anyone realizes that it is never going to meet its termination condition.

Should tool-call guardrails be enforced in-framework or at a gateway?

Both, where possible. An in-framework hook can have access to the reasoning context of the agent and the current task being performed by the agent; a gateway can observe all requests that the process sends out of the agent and cannot be evaded by the agent's code. They each have a blind spot that the other does not.

Why is the gateway considered a hard-to-bypass enforcement point?

Since it's not in the agent's process and is looking at the traffic as it flows over the wire, an agent is unable to "route around a gateway" in the same way that a developer might be able to "route around a hook" on a particular tool. It is the same policy for all calls, irrespective of the framework or model from which they originated.

How do tool-call guardrails handle malformed or typo'd tool calls?

The tool function doesn't even run if the arguments passed to it are incorrect, for example, if it takes a date but is passed a string, or if some fields are missing from the call. If the arguments passed to the tool function are incorrect, e.g., a date is expected but a string is passed, or one of the fields required by the call isn't present, then the call will be rejected by schema validation before it ever reaches the tool function.

What role does human-in-the-loop approval play in tool-call guardrails?

It helps to route specific high-impact actions (e.g., transfer over a threshold or to a system of record) to a human decision rather than an automatic allow/block. It's only if it's scoped very narrowly and only for actions that make a real difference does it last in production; if it's applied to all actions, it builds up a backlog of actions for teams to review that they eventually turn off.

How are tool-call guardrails audited for compliance purposes?

All authorizations must generate a log entry that is tamper-proof and contains the following information: Agent's name, tool call requested, policy evaluated, result, and a timestamp, with the default result being denying access to the tool if no authorization was just made. When a review occurs, that log is what maps to SOC 2, HIPAA, GDPR, and other framework requirements.

Do tool-call guardrails apply to MCP-based tool calling specifically?

Yes, but by introducing failure modes directly into the protocol, generic tool-call guardrails must be able to handle them too, such as having an MCP server run the tool with its own access rights instead of the client's (confused deputy) and the tool being poisoned by an altered description or response (tool poisoning).

What happens when an agent tries to call a tool outside its allowlist?

The call is rejected structurally, as the tool was never registered to that agent identity in the first place, but rather by the runtime evaluation and denial of that call. This prevents a scenario where an unauthorized tool is requested in a hallucination or manipulated request and has any chance of executing.

How does Akto enforce tool-call guardrails for AI agents?

Akto detects all MCP servers, agents, and tools via over 80 connectors, has a guardrail engine that enforces rule or AI-based policies before a call is completed, and red-teams discovered agents with over 1,000 probes to keep its policies updated against new policy violations from tool misuse techniques.