Decide what each agent may do, step by step.
Detection is the same everywhere. Where you draw the line is not. Arkose Titan names the agent, scores the action it is attempting and applies the policy you set for that step. Let agents check balances. Stop them moving money. Keep a record of every decision.
Three populations on the same road.
There is no separate lane for agents. They use the same web, the same logins and the same checkouts as your customers, and most of them do not say what they are.
That puts three populations on your site at once: humans, legitimate agents acting for a customer, and malicious automation using the same tools. "Is this a bot?" was the right question when there were two. With three, blocking everything that is not human means turning away customers, and allowing everything that passes login means letting abuse through on a valid session.
The job has changed. Classify each session, then decide what it may do.
Who is it. What is it trying to do. Did the customer say yes.
Who is it?
Every session is classified as human, self-disclosing agent, non-disclosing agent or malicious automation. Named agents get a persistent Agent ID, so the same agent is recognized across sessions, accounts and networks.
What is it trying to do?
A login, a balance check, a new payee and a password change are not one session score. Each action is scored on its own, so the same agent gets a different verdict for checking a balance than for moving money.
Did the customer say yes?
Some steps should never complete without a person. We're working on proof of human as an orchestration outcome: the agent does the routine work, and the account holder confirms the decisions that matter. Availability to be announced.
Policy by agent, by step and by action. No code changes.
Identify the agent.
Every session is classified and named. Fewer than 3% of agents identify themselves (State of Agentic AI Trust report), so Arkose reads the device, compute, network, behavior and identity layers behind the session instead of taking its word for it.
Map the journey.
Apply policy per endpoint: login, signup, checkout, account recovery, money movement, support.
Choose the response.
Allow, monitor or block, per agent and per step. Good agents through, bad ones out, and a different answer for the same agent at a different step.
Keep the record.
Every decision is recorded as enforced, with what is known now alongside it, in Command Center.
Change it any time.
Rules are self-service in Command Center and take effect immediately. Nothing changes in your code.
Every industry draws the line somewhere different.
What we hear from customers. Most start with visibility, then decide what agents may do at each step.
Same detection everywhere. Your policy should turn on the action attempted, and whether you said yes.
Four things we hear from almost everyone.
- Visibility first. Most teams want a few weeks of data before they set policy.
- The same steps are closed everywhere. Support chat, refunds, password resets and account changes are where almost every business keeps agents out.
- Block, then reopen. Some start by blocking all agents, then reopen read-only steps once they can see the traffic.
- Liability is unresolved. Who is responsible when a third-party agent moves money is still an open question. Today, agents are generally treated as tools of the user.
Detection auditing: what you enforced, what you know now, and what changed.
Agents change constantly. One moves from data centers to home IPs, another stops signing its traffic, a third ships a new device profile overnight. Each time, there is a gap before a detection catches up. Detection auditing closes that gap after the fact and gives you the record.
Re-score your history.
When Arkose names a new agent or corrects a detection, past sessions are re-evaluated on the signals stored at the time.
Two labels, never rewritten.
"As enforced" stays exactly as it was. "Current" shows today's answer. Added agents and removed false positives both show.
Every change, versioned.
Who approved it, why, how it was validated and what it did to your traffic.
Ready for examiners.
Filter by agent or change type. Export for fraud claims, disputes and regulators. Answer "how long was this agent on our platform before it was named?"
Available in Command Center.
See it before you decide.
Two lines of script in the page head. Within 7 days, see which agents are already in your flows, how often, and their share of traffic. Then decide what each one may do.
Frequently asked questions
Why not just block all agents?
Some businesses do, and for some steps that is the right call. But agents also sign up, order, pay and service accounts, and the customer behind one does not know their agent was stopped. They know your site did not work. Most businesses want to allow the steps that bring revenue and close the ones that carry risk. That takes policy per step, not one switch.
Can't agents just identify themselves?
Fewer than 3% do, according to the State of Agentic AI Trust report. The signing standard is still a draft, unsigned identifiers are trivial to spoof, and malicious automation will never sign. A policy that depends on agents volunteering their identity covers only the polite minority.
Can I require a person at certain steps?
Today you can block every agent at the steps that matter most: a new payee, a transfer, a credential change. We're working on proof of human as an orchestration outcome, so an agent that reaches one of those steps can't continue until the person behind it confirms they're there. Availability to be announced.
What happens when an agent changes how it looks?
Detections are updated continuously and one fix ships to every customer, with no rule changes on your side. For the gap before an update lands, detection auditing re-scores past sessions so you can see what was enforced at the time and what is known now.
Serve the agents you want without opening the door to the rest.
Agents are customers now. Arkose Titan lets you decide, step by step, what each one may do, and prove it afterward.
