Session security

ARCY serves a session only from a domain you have proven you control, and it decides which environment a call belongs to from the session itself, never from a value the caller sends. Together the two keep somebody who never touched your dashboard from spending your chat allowance. The dashboard steps for adding and verifying an origin are on Origins; this page is the model behind them.

How the proof works

Proof is a DNS TXT record, the same way a certificate authority or a custom-domain feature proves ownership. For an origin such as https://myapp.com, ARCY issues a value unique to that origin and your Product, and you publish it as a TXT record named _arcy-verify.myapp.com. When you press Verify, the backend looks the record up and compares it.

• Proof is per hostname. myapp.com and app.myapp.com are separate origins with separate records.
• https://myapp.com and https://www.myapp.com are one origin. Verify either and both are trusted. Only a leading www. is folded this way.
• Proof is made once per Product and then assigned to the environments that may use it.
• Nothing is added to your source code, and the proof survives redeploys.

What an unverified origin can and cannot do

An origin you added but have not verified is stored so you can see it is pending, and it is trusted for nothing. It does not pass CORS and it cannot start a session. A Product with no verified origin starts no session from a browser. There is no accidentally open state.

localhost is the one exception. It is trusted on every environment with no record, on the common development ports, so a local install works with no setup.

Where the check runs

The origin check runs when a session starts. It is enforced on your Primary environment, which is where a production Token lives. Every later call, a chat message, a flow step, an event, presents the session it was issued, and the backend reads the environment and the Product from that session, never from the request body. A request cannot join your Product by guessing a session id. A refused start is recorded, so an origin that fails to start a session shows up as a verdict rather than as silence.

When you audit a session

• A session that does not start: check that its origin shows Verified on Origins and is assigned to the environment whose Token the page loads.
• Chat usage you did not expect: it came from a verified origin on a session ARCY issued. Read the sessions on Users to find which one.