AI Application Firewall

The AI Application Firewall checks every turn of every conversation your agents have, in chat, text, phone calls, and the API. It can tell you when a caller's voice sounds synthetic, ask a person to prove who they are before a sensitive tool runs, alert you when someone asks for something they never asked for before, and cap how many sensitive records one person can get. You turn it on for the company, choose which checks to use, and watch what it finds before you let it stop anything.

What it's for

An agent that can look up payroll, change a bank account, or read a patient record is worth attacking. The firewall is built for the attacks that work on people and AI alike:

• A cloned voice. Someone calls your support line sounding exactly like your CFO and asks for this month's payroll file.
• Impersonation by chat or text. Someone claims to be a manager, says it's urgent, and asks the agent to skip the usual checks.
• A stolen login or leaked API key. The requests look legitimate, but they don't match anything this person has done before.
• Slow data theft. Someone asks for one customer record, then another, then fifty more.
• Prompt injection. A document or web page a tool reads tells the agent to send data somewhere it shouldn't.

The same checks are available as an API, so your own applications can use them on conversations that don't run on Autessa. See the AI Application Firewall API.

Navigating here

• Dashboard: from the sidebar, open Company → AI Application Firewall. It shows what the firewall is catching across your agents and the API. See Monitor what the firewall catches.
• Settings: Company → AI Application Firewall → Settings has one section per check, your custom rules, the word of the day, your passphrases, named API policies, and the attack simulator. You need permission to manage team members to change it.
• Alerts: Company → AI Application Firewall → Alerts lists everything the firewall recorded, with a detail page for each alert.
• One agent: open the agent and find the AI Application Firewall card. It also shows a summary of the last 7 days for that agent.
• One tool: open the tool and find Verify before use and Sensitive records.
• Your authenticator app: Account → Password & sign-in.
• Today's word: the Today's word card on your home page and on the Me tab of the Autessa mobile app.

Key concepts

Company policy and agent settings

The firewall starts with a company policy: the checks you turn on and what each one does. Every agent then has one of three settings:

Setting	What it means
Use company policy	The agent follows the company policy. This is the default for every agent once the firewall is on.
Custom	The agent has its own policy, with the same sections as the company Settings page. Use it for an agent that needs stricter or looser rules, such as a payroll agent.
Off	The firewall's checks don't run for the agent. Tools that need verification still ask for it.

The setting covers the agent on every channel: the builder, apps and websites, embedded chat, text messages, phone calls, Slack, the Client API, and agents that run from triggers and scripts. It also covers multi-agents and the agents they call. When you copy an agent or install one from the Marketplace, its firewall setting comes with it.

Monitor and Enforce

The policy has a mode:

• Monitor (the default) records what each check finds on the alerts page, but doesn't stop anything. Risks the firewall detects, such as a synthetic voice, an unusual request, an unverified caller ID, pressure tactics, or a match on one of your custom rules, are only flagged. Use it to see what the firewall would do with your real traffic before you rely on it.
• Enforce applies each check's action: it blocks, asks the person to verify, or holds the request for an admin's approval.

Turning on a new check never changes what your customers see until you switch the policy to Enforce. Start in Monitor, read the alerts for a week or two, adjust the settings, then enforce.

Verify before use on a tool, described below, is always enforced. It's a requirement set by the tool's author, like a private argument, so the person must verify before the tool runs even when the policy is in Monitor or the agent's firewall setting is Off.

Each check also has a setting for when the check itself can't run, for example if the voice check is briefly unavailable:

• Let it through (the default): the conversation goes on, and the error is recorded.
• Stop it: in Enforce, the request is treated as failed.

Actions

Each check has an action. When several checks find something in the same turn, the strongest action wins:

Action	What happens in Enforce
Flag	The turn goes ahead, and an alert is recorded.
Ask to verify	Before the next sensitive tool runs, the person must verify. See Verification before a tool runs.
Require approval	The tool call is held, and admins get a notification to approve or reject it.
Block	The tool doesn't run, and the agent tells the person it can't help with that.

Voice check

On phone calls and in voice chat, each thing the caller says gets a voice score from 0 to 1. The score is how likely it is that the voice was made by a computer, such as a cloned or synthetic voice, rather than spoken by a live person:

• Below 0.5 (the default threshold): treated as a real voice.
• 0.5 or above: treated as synthetic, and the check's action applies: Flag, Ask to verify, or Block. With Block, the agent won't run tools that need verification for the rest of the call, so you can have it transfer the caller to a person or end the call.
• While the caller is verifying, the bar is stricter. The default is 0.35, so a voice that's only borderline isn't enough to pass.

Each score is also labeled Real, Synthetic, or Unsure. Scores show in the call's details and are returned by the Get Caller Info tool, so an agent can take them into account.

What to know about the voice check:

• It's a signal, not proof. A high score means the voice has the marks of computer-made speech. It doesn't prove fraud, and a low score doesn't prove the caller is who they say they are. Pair it with verification for anything sensitive.
• Phone audio is harder. Phone lines carry much less of the sound than a microphone does, which makes the check less certain on calls than in voice chat or on recordings sent to the API. A bad connection, a speakerphone, or a lot of background noise can raise the score of a real voice.
• Short replies aren't scored. Anything under about a second, like "yes" or "okay", is skipped. So is anything said while the caller is typing on the keypad.
• The agent's own voice is left out. In voice chat, moments when the caller's audio overlaps the agent speaking aren't scored, so echo doesn't count against the caller.
• The check runs alongside the call. It never delays the agent's reply. A score applies from the caller's next turn.

Voice watermark

When the firewall is on, your agents' voices carry an inaudible watermark. It doesn't change how the agent sounds. If a caller plays back a recording of one of your Autessa agents, for example to pass a voice check or to replay an agent reading out a code, the firewall recognizes the watermark and treats the audio as synthetic. Recordings sent to the voice score API also report whether they carry the watermark, so you can confirm a clip came from an Autessa agent.

The watermark is on by default. You can turn it off on the Settings page. It's detected most reliably in voice chat and on recordings. Heavy compression, which phone lines use, can weaken it, so treat a missing watermark on a phone call as "unknown", not as proof that the audio is live.

Word of the day

The word of the day is a short, common word that changes every day at midnight. You choose the time zone that midnight is in on the Settings page. It's UTC unless you change it, so set it to where most of your team works. Your team can use the word to prove they work for you:

• Who sees it: members whose role you allow, on the Today's word card on their home page and on the Me tab of the Autessa mobile app. Each time someone views the word, it's recorded on the alerts page. Nobody outside your company can see it, and the agent is never told what it is.
• One word or one per agent: choose one word for the whole company, or a different word for each agent.
• Just after midnight: yesterday's word still works for a short while (60 minutes by default), so a call that started before midnight isn't interrupted.
• Daily reminder: optionally, members get a notification each morning. It says "View today's word" and never includes the word itself.
• Rotate: Rotate words on the Settings page changes every word, including the duress word, right away. Use it if you think a word was overheard or shared.

On a call, the agent asks the caller to say the word inside a short phrase, for example "Please say: river, today's word, seven." The caller must say all three words in order, and the voice check must find that answer to be a live voice. A recording of someone saying the word earlier won't pass, because the other two words are different every time. In chat, the person types the word. The word of the day isn't accepted by text message, because texts can be read by anyone who has the phone.

Duress word

When you turn on the duress word, the Today's word card shows a second word. A member who is being pressured, for example someone forced to call in and request data, says or types the duress word instead of the real one.

What happens next is designed so the person pressuring them can't tell:

• The agent responds exactly as if verification passed.
• Every tool that needs verification quietly answers that it isn't available right now, and nothing runs.
• No sensitive records are shared for the rest of the conversation.
• Admins, and any contacts you name, get an urgent security notification with a link to the call or conversation.

The duress word is always different from the real word and never sounds like it.

Verification before a tool runs

Turn on Verify before use on any tool that gives out or changes something sensitive. Before the tool runs, the agent pauses and asks the person to verify:

• If you list methods on the tool, the person is asked for each of them, one after another, and must pass them all. For example, list the word of the day and the authenticator app to require both.
• If you don't list any, the company's methods from the Settings page are used, and any one of them is enough. The first one that works for this person is asked for.

Method	How the person verifies	Where it works
Word of the day	Says or types today's word.	Chat and phone calls, not text messages
Passphrase	Types the passphrase you chose for the tool. Passphrases are at least 14 characters, and they're saved only in a form that can be checked but never read back, so nobody, including Autessa, can look one up later.	Chat only. A passphrase is never asked for on a phone call, where it would be heard and recorded, or by text message.
Authenticator app	Enters the 6-digit code from their authenticator app. On a phone call, they type it on the keypad.	Chat, phone calls, and text messages
Approve on your phone	Taps Approve on a notification in the Autessa mobile app (or in their inbox on the web). The request works once and expires after 2 minutes. If there's no answer after 45 seconds, the person is asked again.	Chat, phone calls, and text messages, for company members

If a tool lists a method that can't be used in the conversation, such as a passphrase on a phone call, the person can't verify there and the tool doesn't run. Choose methods that suit the channels the agent works on.

What to know:

• The AI never sees the answer. The person's answer goes straight to the check. In the conversation history it's replaced with "[verification answer hidden]", and it never reaches the model, your logs, or stored transcripts.
• On a call, codes go through the keypad. The agent reads out the request, the caller types the code on their keypad the same way Secure Keypad Capture works, and the AI never hears the digits.
• Who the person is. Authenticator codes and phone approvals belong to a person, so the firewall has to know who it's talking to. In chat, that's the signed-in member. On a call, it's the member who added the caller's number to their authenticator app setup (see How to set up your authenticator app), and only when the carrier verified the caller ID, so the number wasn't spoofed. If the caller can't be matched to a member, they can only verify with the word of the day.
• How long it lasts. Once verified, the person doesn't have to verify again for 30 minutes by default. You can set a different time on each tool, up to 24 hours. Verification ends early if the voice score rises past the threshold, or if a new person joins the call.
• Wrong answers. After 3 wrong answers, verification is locked for that conversation for 15 minutes, and admins are notified. The lock applies to that conversation only, never to the member's account or their authenticator app, so an attacker can't lock your staff out. If the same person is locked out 3 times in a day, admins get a security alert.

When the firewall asks someone to verify because of another check, such as a synthetic voice or an unusual request, it uses the same steps at the next sensitive tool.

Unusual-request alerts

The firewall learns what's normal for each person who talks to each agent and alerts you when a request doesn't fit. A person is a signed-in member, a user of your application through the API, a caller's phone number, or a website visitor.

Each request is compared with that person's own history on that agent:

• the tools they use, and the details they ask for
• the channel they use, and the day and hour
• where the request comes from: the country and network, or the phone number's country and carrier
• how many requests they make in an hour
• whether the message is very different from what they usually ask

For each person, the first 10 requests are only learned from, so nothing is flagged while there's no history to compare against. After that, a request that stands out raises an Unusual request alert that says in plain words what was different, for example "First time this caller asked for Get payroll; new country". Sensitivity (Low, Medium, or High) sets how different a request must be. The action can be Flag, Ask to verify, or Require approval.

Alerts show on the alerts page, and admins get a security notification in their inbox that links to it.

Caller ID check

Phone carriers sign most calls to show whether the caller's number is real. The firewall reads that result on every incoming call:

Result	Meaning	Default action
Verified	The carrier confirmed the caller may use this number.	Allow
Partly verified	The carrier knows the caller, but not that they own this number.	Flag
Not checked	The call arrived without a result, which is common for calls from abroad or older networks.	Flag
Failed	The carrier's check failed, so the number may be spoofed.	Ask to verify

You can set each result to Allow, Flag, Ask to verify, or Block. A number that isn't verified is never matched to a member for authenticator codes or phone approvals. The result shows in the call's details and in the Get Caller Info tool.

Pressure-tactics check

Social engineering relies on pressure. This check reviews the recent conversation for the signs: a rush ("this has to happen in the next ten minutes"), someone claiming to be an executive or IT, a request to skip verification, gift cards, a change to payment or bank details, or a request to keep it secret.

To keep the cost down, it doesn't run on every turn. It runs only when a sensitive tool is about to run or when the person may need to verify. The alert quotes the words that raised it. The action can be Flag, Ask to verify, or Require approval. Because it uses an AI review, it costs more firewall points than the other checks.

Sensitive-record limits

You can cap how many sensitive records one person can get from your agents, per conversation and per rolling 24 hours.

You decide what a sensitive record is. Nothing is guessed by AI. A record counts only when a person on your team has said it does, in one of two places:

• On a tool. In the tool's Sensitive records setting, mark it as returning sensitive records and choose how to count them:

  Count	Use it when	Example
  1 per call	Each call returns one record.	Get employee: each call counts 1.
  Each item in a list	The result is a list of records. Give the list's path, such as results.	Search customers: 25 results count 25.
  Each distinct value	The result can repeat the same record. Give the path to the value that identifies it, such as results[].employeeId.	A payroll report with 3 rows each for 10 employees counts 10.

  You can add a label, such as "employee records", which is used in alerts.

• On an AutessaDB table. The table's owner turns on Contains sensitive records. Each row an agent reads from that table counts as 1. Rows from tables with columns marked as masked count too.

Tools and tables nobody has marked never count, however personal the data in them looks.

When a person reaches a limit, the action applies: Block, Ask to verify, or Require approval. With Block, the tool politely refuses, the agent tells the person it can't share more right now, and an alert is recorded. The counts follow the same person as unusual-request alerts, so starting a new conversation doesn't reset the daily count.

Tool and data checks

The firewall also watches what tools do:

• Allowed tools: list the tools an agent may call. Anything else is blocked.
• Allowed sites: list the sites tools may send data to. A request to a new site needs approval.
• New email domains: an email to a domain the agent hasn't used before needs approval.
• Secrets and personal data: a tool request that would send a secret to another site is blocked, and one that would send personal data to another site needs approval. A reply that contains a secret is blocked.
• Prompt injection: text that tries to give the agent new instructions, in what a person says or in what a tool returns, is flagged. After that, any tool in the same run that sends data to another site needs approval.
• Rows read: a cap on how many rows one agent run can read.
• Loops: the same tool called 5 times with the same request in one run is stopped.

Custom rules

Custom rules let you shape the firewall to your business, the way you would set up rules on a network firewall. They run after the built-in checks, on the company policy, on an agent's Custom policy, and on named API policies.

There are two kinds of rule:

• Rules add a finding with the action you choose: Allow, Flag, Ask to verify, Require approval, or Block. For example: "If the channel is phone and the voice score is above 0.4, ask for verification", or "If the tool is Change bank details and the request comes from outside the US, block it."
• Exceptions remove built-in findings you've decided don't matter in a situation. For example: "If the person is a verified member and the site is api.payroll.example.com, ignore new-site alerts."

Each rule has:

• Name: shown in alerts, so make it say what the rule is for.
• When it applies: which points in the turn it checks, such as the person's message, a tool call, a tool's result, the reply, or the caller's voice. Leave it empty for all of them.
• Conditions: up to 10, each a field, a comparison, and a value, such as "voice score is above 0.4" or "country is not US". Choose whether all conditions must match or any of them. You can compare the channel, the agent, the tool and whether it needs verification or returns sensitive records, who the person is and whether they've verified, the country or IP address, the hour and day of the week (in your company's time zone), the voice score, the caller ID result, the unusual-request score, the prompt-injection score, whether pressure tactics were found, sensitive-record counts, the site or email domain a tool sends to, the text of the message or reply, the tool's inputs, and how many tool calls or rows the run has used. Text can be matched with a pattern of up to 200 characters.
• Action (rules) or findings to ignore (exceptions).
• Stop: when this rule matches, later rules aren't checked. A rule with Allow and Stop works as an explicit allow.
• Note: optional, for your team.

Order matters. Rules are checked from top to bottom, and you can move them up and down in the list. After all matching rules have been applied, the strongest remaining action wins. A policy can have up to 100 rules.

Exceptions can't skip safety checks. The duress word, verification lockouts, a secret about to leave in a tool request, a check that couldn't run, and a tool's own Verify before use are protected checks that an exception can never remove. An exception that lists a protected check is rejected when you save the policy.

Preview before you save. Preview against the last 7 days shows how many recent requests the rule would have changed, for example how many would now be blocked or asked to verify, with examples. Rules that look at the text of a message or a tool's inputs can't be previewed for past traffic, because that text isn't kept with alerts. The preview tells you which rules that applies to. Each rule in the list also shows how many times it matched in the last 7 days.

In Monitor, rules only flag. In Enforce, their actions apply.

Alerts and approvals

Company → AI Application Firewall → Alerts lists what the firewall recorded: when, which agent and tool, the check, the action, and whether it was applied (Enforce) or only recorded (Monitor). Every column can be sorted. Open an alert to see the details, such as the voice score, what was unusual about a request, or the quoted pressure cues, with a link to the conversation or call.

An alert that needs approval has Approve and Reject. Approving lets that agent run that tool with that exact request. The security notification admins get in their inbox has the same buttons and opens the alert.

Requests that pass every check are recorded only as a sample, so the list stays readable.

Pricing

The firewall is priced in firewall points, at the same price for agents and for the API. Each check that actually runs adds its points. A check that's turned on but doesn't apply, such as the caller ID check in a chat, costs nothing. Verification is charged for each attempt, meaning each answer the person gives, not when they're asked to verify. In agents, the points are added on top of the conversation's normal task. See Billing for the points per check.

Privacy

• No voiceprints. The voice check scores each thing the caller says and keeps only the score. It doesn't build or store a profile of anyone's voice.
• Answers are hidden. Verification answers are never shown to the AI, stored in transcripts, or logged.
• Retention. Alerts, scores, and verification records are deleted after 30 days.
• Unusual-request history is kept as counts and summaries per person, not as copies of their messages.

How to turn it on

1. Open Company → AI Application Firewall → Settings.
2. Leave the mode on Monitor.
3. Turn on the checks you want and set each one's action. Each section saves its own settings.
4. Every agent now uses the company policy. To change one agent, open it, find the AI Application Firewall card, and choose Custom or Off.
5. Watch the dashboard and Alerts for a week or two. Adjust thresholds and actions where you see false alarms.
6. Switch the mode to Enforce.

Monitor what the firewall catches

Company → AI Application Firewall opens the dashboard: one page that shows what the firewall is checking and catching, for your agents and for the API. It refreshes every minute while it's open. Until the firewall is on, it offers to turn it on or to run the attack simulator.

Filters. At the top, choose:

• the date range: the last 24 hours, 7 days, 30 days, or custom dates
• the source: All, Agents, or API
• one agent or one API policy, to see only its traffic

The numbers. A row of totals for the range: Checks, Caught, Blocked, Verifications passed and failed, and Points used. Each shows the change from the previous period of the same length, for example the 7 days before this week.

The chart. Checks over time, split by outcome: allowed, flagged, asked to verify, sent for approval, and blocked. Ranges of 48 hours or less are shown by hour, longer ones by day.

What it caught. A bar for each kind of catch, such as synthetic voices, unusual requests, unverified caller IDs, pressure tactics, sensitive-record limits, and custom rule matches, with how many were applied in Enforce.

Agents and API policies. Two tables: one row per agent and one per API policy, with checks, catches, blocks, and points. Every column can be sorted. Click a row to filter the dashboard to it.

Top rules. Your custom rules that matched most often.

Top identities. The people with the most catches, and when each was last seen. They're shown masked, such as "Caller •••4421", "Member: Jane D.", or "API subject a1…f9".

Recent catches. The latest things the firewall caught. Click one to open the alert.

Pending approvals. When requests are waiting for an admin, a banner says how many and links to them.

The counts include every check, even though passing checks are kept on the alerts page only as a sample. Attack simulator runs aren't counted.

To see one agent, open the agent's AI Application Firewall card. It shows the last 7 days of checks, catches, and blocks, with a small chart, and View on dashboard opens the dashboard filtered to that agent. Your own applications can read the same numbers with the dashboard API.

How to require verification before a tool runs

1. Open the tool and find Verify before use. Turn it on.
2. Choose the methods for this tool. Every method you list is asked for in turn. Or list none to use the company's methods, where any one is enough.
3. If you list Passphrase, choose which passphrase the tool accepts.
4. Optionally set Verify again after, for example 5 minutes for a tool that changes bank details.
5. Save and publish the tool.
6. On the Settings page, under Verification, check the methods your company allows, the number of attempts, and the lockout time.

To create a passphrase, open Company → AI Application Firewall → Settings → Passphrases, click New passphrase, and give it a name and the phrase. It must be at least 14 characters. Share the phrase only with the people who need it. You can't view a passphrase after you save it, only replace or delete it.

How to set up your authenticator app

1. Open Account → Password & sign-in and find Authenticator app.
2. Click Set up and scan the QR code with an authenticator app, such as Google Authenticator, Microsoft Authenticator, or 1Password.
3. Optionally enter Phone number you call from, with its country code, such as +14155550100. Add it if you'll verify on phone calls to your agents.
4. Enter the 6-digit code the app shows, and click Confirm.

The QR code is shown only once. To move to a new phone, remove the authenticator and set it up again.

The phone number lets an agent know a call is from you, so it can ask for your authenticator code or send an approval to your phone. It's used only when the carrier verified the caller ID on the call, so someone faking your number can't use it. Afterward, only its last 4 digits are shown. To verify on a call, type the code on your phone's keypad when the agent asks.

How to use the word of the day

1. On the Settings page, turn on Word of the day, choose who can see it, and choose one word for the company or one per agent.
2. Optionally turn on the duress word, and name anyone besides admins who should be alerted.
3. Tell your team where to find Today's word, and what to do with the duress word.
4. Add Word of the day to the verification methods of the tools that need it.

On a call, when the agent asks you to verify, say the three words it reads out, in order, with today's word in the middle. In chat, type today's word.

How to set sensitive-record limits

1. On each tool that returns sensitive records, open Sensitive records, turn it on, and choose how to count.
2. On each AutessaDB table that holds sensitive records, turn on Contains sensitive records.
3. On the Settings page, under Sensitive records, set the limit per conversation, the limit per day, and the action. An agent with a Custom policy can have its own limits.

How to add a custom rule

1. Open the Rules section on the Settings page, on an agent's Custom card, or on a named API policy.
2. Click New rule, and choose Rule or Exception.
3. Give it a name, choose when it applies, and add its conditions. The summary under the editor reads the rule back in plain words, so check it says what you mean.
4. Choose the action, or the findings an exception ignores, and whether to Stop after it matches.
5. Click Preview against the last 7 days and check the results.
6. Save, then move the rule to the right place in the list.

How to test with the attack simulator

The attack simulator (25 firewall points per run) runs a built-in set of attacks against an agent or a named API policy and shows how the firewall did. The attacks include:

• prompt injection and attempts to override the agent's instructions
• pressure tactics and impersonation
• guessing passphrases, and replaying an old word of the day
• requests that don't fit a person's history
• trying to get more sensitive records than the limit allows
• cloned voices, using prerecorded audio, so no calls are placed

It's a dry run. During a simulation, tools never actually run. They return a made-up result, so nothing is sent, changed, or charged. The firewall's decisions are recorded and tagged as a simulation, so they don't count toward anyone's history or sensitive-record limits, and they don't send notifications.

1. On the Settings page, open Attack simulator.
2. Choose an agent or a named policy, and the kinds of attacks to try.
3. Click Run.
4. Read the scorecard. For each kind of attack, it shows how many were tried, blocked, flagged, and got through. Open a row to see the alerts each attack produced.

Run it again after you change the policy, to see the difference.

How to use the firewall in your own application

The checks are also available through the AI Application Firewall API with a client API key. Your application sends each turn of a conversation to the API and gets back what to do. Create named policies on the Settings page, under API policies, to keep different settings for different applications.

Related

• AI Application Firewall API
• Protect Sensitive Data
• Response Checks
• Phone Numbers
• Tools
• Agents
• Phone & SMS tool types
• Agents API (poweruser)