# OmniArx > OmniArx is human approval for AI agent actions. Before an AI agent pays, shares data, grants access or changes a system, a person approves the exact action on their phone. A hardware key on the phone signs exactly what the person saw and exactly what will run. A check in front of the API lets that one request through, once, and refuses anything changed. It is built for banks, fintechs, AI assistant platforms and any team whose agents act on real systems. OmniArx answers one question: how do you prove a person approved this exact action before your AI agent carried it out? It is a security layer for agentic AI, sometimes called AI agent authorization, human-in-the-loop approval, transaction authorization or transaction signing. The approval covers the rendered text the person read ("what you see is what you sign"), the action and its parameters, and optionally the exact HTTP request. This file holds the readable text of every page on omniarx.ai, generated from the site itself. Interactive demonstrations and forms are left out. The short index is at https://omniarx.ai/llms.txt and structured facts are at https://omniarx.ai/agent-guide.json. --- ## Page: https://omniarx.ai/ ### Make sure your AI only pays what you approved. **Security for AI actions.** You approve each action on your phone. Only that exact action runs. Anything changed is refused. #### Your agent can read instructions nobody gave it. A webpage, document or message can hide instructions planted by someone else. If the agent follows them, its next action changes. ##### The customer asked it to pay a supplier. **A familiar task becomes a different action:** the hidden instructions change who gets paid. The agent may still call the task “paying the invoice.” OmniArx builds the approval screen from the request itself, never from text the agent wrote. The person sees the real payee. A request that differs from what they signed is refused at your API. #### The approval has to survive the trip to your API. ##### The agent asks Your agent proposes an action. Nothing runs yet. OmniArx builds the approval screen from the request itself, never from text the agent wrote. ##### The person answers The screen is drawn on their phone, in a frame that refuses to sign if anything covers it. Sliding to approve opens a fingerprint or face check. Only then does a key held in the phone's hardware sign the text on screen and the request it describes. ##### The API checks The OmniArx proxy in front of your API checks the signature and spends it once. The request that was read is the request that runs. Anything else is refused by name. If anything is missing, it refuses. It never guesses. #### Industries: pick the action you need protected. The same check works wherever an agent acts. Each page shows the actions it protects in that industry. *Banking & fintech* ##### Payments to new payees ([page](https://omniarx.ai/industries/banking-fintech)) Your customer approves each payment on their phone. Only that exact payment runs. A changed payee or amount is refused. *AI chat platforms* ##### Every action an assistant takes ([page](https://omniarx.ai/industries/ai-chat-platforms)) Each action your assistant takes gets its own signed approval from the customer's phone. Proof from outside the assistant. *Privileged IT access* ##### Admin access and risky commands ([page](https://omniarx.ai/industries/privileged-access)) Your access tool can't prove what the approver saw. OmniArx signs the exact role, target and command on their phone. *Healthcare* ##### Orders and record releases ([page](https://omniarx.ai/industries/healthcare)) The clinician signs the exact order or release on their phone. Only what they read is sent. *Logistics* ##### Reroutes and carrier payments ([page](https://omniarx.ai/industries/logistics)) A planted instruction can quietly reroute goods or money. OmniArx makes each change wait for a signed yes. *Manufacturing* ##### Settings and production orders ([page](https://omniarx.ai/industries/manufacturing)) A changed setting costs material and downtime. The engineer signs the exact change on their phone before it runs. *Defense* ##### Releases, access and purchases ([page](https://omniarx.ai/industries/defense)) Each release, access change or purchase is signed on the officer's phone, tied to the exact screen they read. *Bring your own action* ##### The one action you choose ([page](https://omniarx.ai/industries/bring-your-own-action)) Two small pieces of code you own: what the person must see, and how strong the approval must be. #### One SDK in your app. One check in front of your API. You build OmniArx into the app your customers already use, and put the check in front of the API that runs the action. - **In your app**: The OmniArx SDK for Android and iOS, which Flutter apps use too. It sets up the phone, shows the approval screen, asks for a fingerprint or face, and signs with the phone's hardware key. Your app keeps its own look around it. - **In front of your API**: The OmniArx proxy checks the token, spends it once and forwards the request unchanged. Your API is not modified. - **For your agents**: An MCP server lets an agent ask for approval and wait until it verifies. Submitted to the IETF as individual Internet-Drafts. An Internet-Draft is not an IETF standard. *The approval token* ##### OASNT ([page](https://datatracker.ietf.org/doc/draft-thallapelly-oasnt/)) Defines the display digest: the claim that binds a token to the exact rendered text the person approved. It also binds the action and, if needed, one HTTP request. *The enforcement point* ##### OASNT-ENFORCE ([page](https://datatracker.ietf.org/doc/draft-thallapelly-oasnt-enforce/)) Checks the token against the request the proxy will actually forward, spends it once and refuses with named causes. The protected service does not change. *The action identifier* ##### OASNT-CAID ([page](https://datatracker.ietf.org/doc/draft-thallapelly-oasnt-caid/)) Gives every executor one way to derive the action identifier. It also checks that the person named in the token is the person enrolled for the key. #### Know what you’re trusting. Clear boundaries are part of the protection. **Q:** Does OmniArx stop prompt injection? No. An agent can still read and follow planted instructions. OmniArx makes sure the result cannot run without a matching approval. The approval screen is built from the request, so the person sees the real details. A request that differs from what they signed is refused. Protection covers only the routes behind the OmniArx check. **Q:** What if the person approves the wrong thing? The signature proves what was shown and approved. It does not prove the person understood it. If the screen shows the wrong payee and they approve, the approval is valid. That is why the screen is built from the request itself, and why it refuses to sign when anything covers it. **Q:** Does my API need to change? No. The check runs in a proxy in front of your API, which forwards the request unchanged. You point the route at OmniArx, declare the lowest assurance the route accepts, and map the route to the action the person approves. The person approves in your own mobile app, with the OmniArx SDK for Android or iOS inside. Flutter apps use the same SDK. Coverage for customers without the app is in design. **Q:** What happens when a check fails? The request is refused and never reaches your API. On the wire the answer is a plain 403 that names nothing. Your operator log records the cause by name, for example a changed request, a reused approval or a key that is not enrolled. A new cause gets a new name. We never widen an old one to cover it. **Q:** What if something is missing or set up wrong? The check says no. It never guesses and never falls back to a weaker check. Each protected route must state how strong an approval it needs. A route that states nothing will not start. If the proof from the phone is missing or weaker than the route needs, the request is refused. **Q:** Does a match guarantee the right outcome? A match proves the request is the one that was approved. It does not prove that outside conditions are unchanged, such as an account balance, or that the action will succeed. An approval lasts minutes at most and works once. **Q:** Can I use the SDK in my own app? Yes. The SDK goes into your existing Android or iOS app. Flutter apps use the same Android and iOS builds, so no extra plugin is needed. It shows the approval screen inside a protected frame, runs the fingerprint or face check and signs with a key held in the phone's hardware. It also checks the phone for signs of tampering, such as rooting or hooking tools. Contact us for access to the SDK. **Q:** Can I see it working? Yes, in a live working session. We drive it and you name the case. There is no public download of the verifier or the test kit. **Q:** What can an AI agent find on this website? The [machine-readable reference](https://omniarx.ai/agent-guide.json) gives a product description, specification links, integration requirements and limits. It is an evaluation resource. It is not a live approval API or an integration credential. #### Priced per protected action, not per seat. The value is the action, so that is what we price. Every deal starts with a conversation, because every deal starts with a route map. All prices in USD · Proposal, subject to the design-partner round and final agreement. ##### Design partner $0 USD Up to **50,000** protected actions / month. Named reference, witnessed evidence session and joint measurement of one route. ##### Pilot $30,000 USD fixed · 90 days **One route** one enforcement point - Test replay first, then read-only live traffic - Witnessed evidence session on your own results - Fee credits in full against Entry if signed within 90 days of pilot close ##### Entry $150,000 USD / year Up to **500,000** protected actions / month - One channel - One enforcement point - Standard refusal set ##### Scale $250,000 USD / year Up to **3 million** protected actions / month - Multiple enforcement points - One confirmation covers a plan and its alternatives - Assurance floor per route ##### Platform Custom pricing in USD Above **3 million** protected actions / month - Embed in your platform - Per-action rate, negotiated - Channel and vendor partnerships Proposal. Scope is confirmed in the contract. Overage is priced per thousand protected actions. There is no self-serve checkout. #### Bring the route you want to protect. Tell us what your agent does and which API it calls. We will map the route, the approval screen and where the check goes. ##### What a session covers - The details a person sees and approves - What happens when a request changes - Where the check sits in front of your API --- ## Page: https://omniarx.ai/about ### About OmniArx OmniArx makes sure an AI agent only does what a person approved. The person approves the exact action on their phone, and the API refuses anything else. #### What we build - **An SDK in your app.** It shows the approval screen, asks for a fingerprint or face, and signs with a key held in the phone's hardware. - **A check in front of your API.** It lets the approved request through once and refuses anything else, by name. - **Open drafts.** The approval token and its checks are written up as Internet-Drafts submitted to the IETF. They are not IETF standards. #### Team ##### Arun Thallapelly Author of the OASNT Internet-Drafts. #### Company **Company:** OmniArx FZE **Parent company:** ADVITLABS FZCO, Dubai **Registered in:** Sharjah, UAE (free zone) **Location:** Dubai, UAE **Contact:** [hello@omniarx.ai](mailto:hello@omniarx.ai) --- ## Page: https://omniarx.ai/industries/banking-fintech ### Make sure your AI only moves money your customer approved. Your customer approves each payment on their phone. Only that exact payment runs. A changed payee or amount is refused. #### Where a yes has to be proven. Your assistant can already read balances. Once it can pay, a login session is all that stands behind the payment. OmniArx replaces that with a signature from the customer's phone, tied to the exact screen they read and the exact request that runs. Actions that need a person's approval: - **Payment to a new payee:** AED 40,000 (Payee: Never paid before; Account: Ending 4821). Refused if the payee or amount changes. - **Transfer:** $3,000.00 (From: Checking; To: Savings). Refused if the destination account changes. - **Card payment:** $1,240.00 (Card: Ending 0917; From: Checking). Refused if a different card or amount is sent. - **Credit limit increase:** $12,000 (Current limit: $5,000; Customer: Card holder). Refused if the new limit is higher. #### How it works. ##### The agent asks Your assistant proposes the payment. No money moves yet. The approval screen is built from the payment request, never from the assistant's words. ##### The person answers Your customer sees the payee, amount and account on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of your payments API compares the signed payment with the request. A different payee or amount is refused before any money moves. #### Tested on real phones. - When a customer disputes a payment weeks later, you hold their signature over the exact screen they read, not only your own logs. - It replaces the session behind in-app payments. It does not replace your login or your fraud checks. - It proves what the customer was shown and approved. It does not prove they understood it, or that nobody talked them into it. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/ai-chat-platforms ### Prove your customer said yes to each action your assistant takes. Each action your assistant takes gets its own signed approval from the customer's phone. Proof from outside the assistant. #### Where a yes has to be proven. The banks you sell to ask how an action by your assistant gets authorized. A confirmation inside the chat is a record the assistant keeps about itself. OmniArx adds proof from outside the assistant: a signature from the customer's phone for each action. Actions that need a person's approval: - **Send money to a contact:** $500.00 (To: Matt Lee; Account: Ending 2290). Refused if the lookup picks a different Matt. - **Pay a card bill:** $1,240.00 (Card: Ending 0917; From: Checking). Refused if the amount changes. - **Hold a bill:** Hold (Payee: Internet bill; Until: Next statement). Refused if a different bill is held. - **Move to savings:** $3,000.00 (From: Checking; To: Savings). Refused if the destination changes. #### How it works. ##### The agent asks Your assistant calls two tools: one to request approval and one to check it. One chat sentence can hold many actions. Each one is approved on its own. ##### The person answers Your customer slides to approve each action, in the words they read, then confirms with a fingerprint or face. We never approve a whole chat sentence at once. ##### The API checks The check in front of the banking API verifies each request. An assistant that skips the tools arrives with no approval and is refused. #### Answer the question once for every bank. Ship OmniArx with your platform and give every bank the same answer to how an action is authorized. Priced per protected action. We show it live in a working session. - It works alongside your confirmation step. It adds proof from outside the assistant. - Your assistant and your model stay the same. The check sits in front of the API that runs the action. - Each approval works once and expires within minutes. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/privileged-access ### Make sure your AI only gets the access an admin approved. Your access tool can't prove what the approver saw. OmniArx signs the exact role, target and command on their phone. #### Where a yes has to be proven. Your access tool already has an approval step. It cannot prove what the approver saw. Session recording shows what happened afterwards, not what was approved. Actions that need a person's approval: - **Break-glass access:** 30 min (Role: db-break-glass; Target: prod-db-01). Refused if a different role or target is requested. - **Run a command:** DROP SCHEMA billing CASCADE (Target: prod-db-01; Run as: db-admin). Refused if a different command is sent. - **Grant an admin role:** Admin (Person: Sam Rivera; For: 1 hour). Refused if the role or time is longer. - **Production write:** UPDATE 1 row (Table: customers; Target: prod-db-01). Refused if more rows or another table is touched. #### How it works. ##### The agent asks Your agent or engineer asks for access. Nothing opens yet. The approval screen is built from the access request itself. ##### The person answers The approving admin sees the role, target and command on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of your access system compares the signed request with the real one. A swapped command or a reused approval is refused. #### Tested against a real access tool. Measured against a real open-source access tool. A swapped command was refused. A reused approval was refused. - An access tool grants a role for a time window, not one command. OmniArx proves the approval. It does not limit what runs inside that window. - We do not replace your access tool. Commercial access tools are not integrated yet. - Each approval works once and expires within minutes. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/healthcare ### Make sure your AI only releases what the clinician approved. The clinician signs the exact order or release on their phone. Only what they read is sent. #### Where a yes has to be proven. When an agent acts on a patient record, who can prove the clinician saw it? OmniArx puts the clinician's signature on the exact order or release they read. Actions that need a person's approval: - **Controlled-substance order:** Oxycodone 5 mg (Quantity: 20 tablets; Patient: MRN ending 4471). Refused if the drug or quantity changes. - **Records release:** 412 records (To: Outside research partner; Scope: Visit notes). Refused if more records or another recipient is sent. - **Prior authorization:** MRI, lumbar spine (Payer: Health plan; On behalf of: Dr. Patel). Refused if the procedure changes. - **Address correction:** New address (Patient: MRN ending 4471; Field: Home address). Refused if a different field changes. #### How it works. ##### The agent asks The agent drafts the order or release. Nothing is sent yet. The approval screen is built from the request itself, never from the agent's words. ##### The person answers The clinician sees the drug, quantity or recipient on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of your clinical API compares the signed request with the real one. Anything different is refused before it is sent. #### Measured on your system. We measure it on your own system. A pilot runs on one of your routes and ends with a live evidence session on your own results. - A controlled substance and an address correction do not need the same proof. Each route sets its own approval strength. - It proves what the clinician was shown and approved. It does not prove they understood it. - We make no claim about any health-data regulation. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/logistics ### Make sure your AI only reroutes what someone approved. A planted instruction can quietly reroute goods or money. OmniArx makes each change wait for a signed yes. #### Where a yes has to be proven. Agents now book freight, change deliveries and pay carriers. A planted instruction in an email or a shipping document can quietly change where goods or money go. Actions that need a person's approval: - **Change a delivery address:** New address (Shipment: SHP-20931; Deliver to: Warehouse 7). Refused if a different address is sent. - **Pay a carrier:** $18,400.00 (Carrier: Blue Line Freight; Account: Ending 5512). Refused if the carrier account changes. - **Release a container:** MSKU 482193-0 (Release to: Blue Line Freight; Port: Terminal 2). Refused if the release goes to someone else. - **Change carrier bank details:** New account (Carrier: Blue Line Freight; Account: Ending 7740). Refused if a different account is sent. #### How it works. ##### The agent asks Your agent proposes the change. Nothing moves yet. The approval screen is built from the request itself, never from the agent's words. ##### The person answers Your operator sees the shipment, address or account on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of your logistics API compares the signed request with the real one. A changed address or account is refused. #### Measured on your system. We measure it on your own system. A pilot runs on one of your routes and ends with a live evidence session on your own results. - Bank-detail changes for carriers are a common fraud path. Each one needs a person's signature. - It proves what your operator was shown and approved. It does not check whether the carrier is genuine. - Your API is not modified. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/manufacturing ### Make sure your AI only changes what an engineer approved. A changed setting costs material and downtime. The engineer signs the exact change on their phone before it runs. #### Where a yes has to be proven. Agents that plan production can also change it. A recipe setting, a production order or a supplier order changed by a bad instruction costs real material and real downtime. Actions that need a person's approval: - **Change a recipe setting:** 210 °C (Setting: Oven 3 temperature; Was: 180 °C). Refused if a different setting or value is sent. - **Release a production order:** 5,000 units (Product: Part 44-A; Line: Line 2). Refused if the quantity or line changes. - **Supplier order:** $62,000.00 (Supplier: Steel supplier; Material: Sheet, 2 mm). Refused if the supplier or amount changes. - **Deploy a line program:** Version 4.2 (Line: Line 2; Window: Night shift). Refused if a different version or line is sent. #### How it works. ##### The agent asks Your agent proposes the change. Nothing changes yet. The approval screen is built from the request itself, never from the agent's words. ##### The person answers The engineer sees the setting, value and line on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of the system your agent calls compares the signed request with the real one. Anything different is refused. #### Measured on your system. We measure it on your own system. A pilot runs on one of your routes and ends with a live evidence session on your own results. - The check sits in front of the business system your agent calls, such as the one that plans production. It does not sit on the machines. - It proves what the engineer was shown and approved. It does not check whether the change is safe. - Your API is not modified. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/defense ### Make sure your AI only releases what an officer approved. Each release, access change or purchase is signed on the officer's phone, tied to the exact screen they read. #### Where a yes has to be proven. When an agent drafts a document release, an access change or a purchase, the record must show exactly what the approving person saw. OmniArx ties each approval to the exact screen they read and the exact request that runs. Actions that need a person's approval: - **Release a document:** Report 17-B (To: Partner organization; Marking: Restricted). Refused if a different document or recipient is sent. - **Grant system access:** Read only (Person: Analyst, unit 4; For: 8 hours). Refused if more access or a longer time is requested. - **Approve a purchase:** $240,000.00 (Vendor: Parts supplier; Item: Spare parts kit). Refused if the vendor or amount changes. - **Change a supply request:** 40 units (Item: Field radio batteries; Deliver to: Depot 3). Refused if the quantity or destination changes. #### How it works. ##### The agent asks The agent drafts the release or request. Nothing is sent yet. The approval screen is built from the request itself, never from the agent's words. ##### The person answers The officer sees the document, recipient or amount on their phone and slides to approve, then confirms with a fingerprint or face. Only then does the phone sign exactly that. ##### The API checks The check in front of the system that acts compares the signed request with the real one. Anything different is refused. #### Measured on your system. We measure it on your own system. A pilot runs on one of your routes and ends with a live evidence session on your own results. - Each approval names the person who made it and the exact screen they read. - It proves what the officer was shown and approved. It does not decide who is allowed to approve. - We make no claim about any government security accreditation. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes. --- ## Page: https://omniarx.ai/industries/bring-your-own-action ### Protect the one action that matters most to you. Two small pieces of code you own: what the person must see, and how strong the approval must be. #### Where a yes has to be proven. An action is two small pieces of code you write and own. One says what the person must see. The other says how strong the approval must be. Actions that need a person's approval: - **Refund above a limit:** $2,400.00 (Order: #88213; To: Card ending 0917). Refused if the amount or card changes. - **Shipping-address change:** New address (Order: #88213; Ship to: 12 Harbour Road). Refused if a different address is sent. - **Payout to a new beneficiary:** $9,800.00 (Beneficiary: Never paid before; Account: Ending 3310). Refused if the beneficiary changes. - **Credit limit increase:** $12,000 (Current limit: $5,000; Customer: Card holder). Refused if the new limit is higher. #### How it works. ##### Describe the screen Describe what the person must see. You write the code that turns the request into the fields shown on the phone. ##### Set the strength Set how strong the approval must be for that route. A route that sets no level will not start. ##### Point the route Point the route at OmniArx. The check verifies each request and forwards it to your API unchanged. #### Measured for your action. Need measured results for your own action? That is what a pilot produces. We measure it on your own system. A pilot runs on one of your routes and ends with a live evidence session on your own results. - A shipping-address change is the retail version of a redirected wire. It deserves the same proof. - You own the code that decides what the person sees and how strong the approval must be. - Your API is not modified. #### Bring the action you want to protect. Tell us what your agent does and which system it calls. We will map the route, the approval screen and where the check goes.