Your Data, Kept in Japan and Kept Apart

Where the site runs, where the data sits, and how it travels.

• Hosted and stored in Tokyo

  Sites and the admin run in Vercel's Tokyo region, the database is in Supabase's Tokyo region, and uploaded files, CVs and recordings are stored in Tokyo.

  Live

• HTTPS only, with HSTS

  Every page is served over HTTPS with a two-year Strict-Transport-Security header, and certificates renew automatically, on our domains and each agency's own.

  Live

• Encrypted, verified database connections

  The application, migrations and every operational script connect to the database over TLS and check its certificate against Supabase's root, so a connection can't be read or redirected on the way.

  Live

• Database reachable by our servers only

  Only the site's servers connect to the database. Its tables aren't exposed through Supabase's public data API: the public roles have no access to the schema the service uses.

  Live

• Nothing sent to third parties by default

  Visitor analytics are first-party, fonts are served from the site's own domain, and embedded videos and posts load only when a visitor chooses to play them.

  Live

• Database refuses unencrypted connections

  Our own connections are already encrypted. This switches on Supabase's server-side setting so the database itself turns away any connection that isn't.

  Due: November 2026

  In progress

One agency's data can't be reached from another's, by design of the database.

• Row-level security on every agency table

  Every row carries its agency's id, and the database refuses any query that isn't for the agency signed in. The rule is forced, so even the table owner is bound by it.

  Live

• The app can't switch the rules off

  The application connects with a restricted database role that can't bypass row-level security, can't delete an agency, and can update only the agency's own settings row.

  Live

• Isolation tested before every release

  An automated test acts as one agency and tries to read, write and change another's data, and checks that agents can't read names, emails or notes. Releases go out only through a gate that runs it.

  Live

• CVs in private storage, one-minute links

  CVs are stored privately in Tokyo, in each agency's own folder. A file's address opens nothing on its own; each download is a one-minute link for a signed-in team member, and it is logged.

  Live

• Consultants' raw recordings kept private

  Raw video and audio takes, and the files made from them, are stored privately. Everything that reads them, including transcription and the AI, gets a short-lived signed link. Only the finished, published video is public.

  Live

• Admin on its own address

  Moves the admin to its own host, apart from agencies' public sites, so a page on one site can never share a browser origin with an admin.

  Planned

Who on your team can sign in, and what each role can open.

• One-time sign-in codes, no passwords to steal

  Team members sign in with a code sent to their work email. Codes are stored only as keyed hashes, expire, and lock after a few wrong tries, counted so that parallel guesses can't slip past the limit.

  Live

• Two-step verification, which owners can require

  Members can add an authenticator app with ten recovery codes, and owners can require it for everyone. Each code works once, and a stolen session can't replace an authenticator that is already on.

  Live

• Five roles, checked on every page and download

  Owner, admin, editor, author, and viewer; an author changes only their own jobs and profile. Each admin page and download names the role it needs, and a page's rule holds however the request is dressed up. An agency always keeps an owner.

  Live

• Sessions that can't be guessed or reused elsewhere

  Sessions are 256 random bits, stored only as a hash, in cookies that scripts can't read and that belong to one agency. The Team screen shows how many browsers each member is signed in on, and can sign a member out everywhere.

  Live

• Single-use sign-in links and a fixed session limit

  Today a team member's session lasts 14 days from their last visit and a sign-in link can be used again within its period. This makes links single-use and ends every session after a fixed time, however active.

  Planned

• Single sign-on with Microsoft or Google

  Lets an agency's team sign in through its own Microsoft Entra ID or Google Workspace, under the agency's own policies.

  Planned

When AirTA Sites staff look at your admin or data, you see it.

• Our access is a seat you can see and remove

  When we help in your admin, we sign in as a named "AirTA Sites support" member on your Team screen, which your owner can remove. No one else can take that name.

  Live

• Every page we open is in your activity log

  Each admin page the support seat opens and each file it downloads is recorded in your activity log, under its own Support tab. Changes it makes are recorded like any member's.

  Live

• Database work needs a reason, recorded first

  Any work on an agency's data in the database goes through one script that runs inside that agency's walls and writes the reason to its activity log in the same transaction. It refuses without a real reason.

  Live

• An activity log no one can edit

  The activity log of who changed what is append-only: the application's database role can add entries but can't change or delete them.

  Live

• Direct console access for incidents only

  The written policy limits direct access to the database console to incidents, each one recorded in the incident log.

  Live

How the code handles what people type, upload and link to.

• Everything written is cleaned before it's shown

  Text an agency or a visitor writes is cleaned before any page or email shows it: no raw HTML and no scripts.

  Live

• Security headers on every page

  Framing, content sniffing, referrers and browser features are locked down on every response, no header names the software behind the site, and downloads and relayed images carry their own stricter sandbox.

  Live

• Every CV a candidate sends is inspected

  Files are judged by their bytes, not their names. Macros, scripts, embedded programs, remote templates, external links in spreadsheets and password-protected files are refused.

  Live

• Outside addresses fetched safely

  When the service fetches a picture or page from an address someone gave it, it checks each connection lands on the public internet, never inside our network, follows redirects one by one, and caps size and time.

  Live

• Stored secrets sealed with AES-256-GCM

  Authenticator secrets, the tokens of a connected Google account and the addresses of webhooks you connect are encrypted before they're stored; a tampered value opens to nothing.

  Live

• Payment and email events verified

  Messages from Stripe and Resend are accepted only with a valid signature, and a paid session grants credits only when it is ours and matches exactly.

  Live

• Spreadsheet exports can't carry formulas

  Exports open in Excel with Japanese intact, and any cell that could run as a formula is neutralised.

  Live

• Every release passes the same checks

  Releases go out through one command that runs type checks, the full test suite, lint, the isolation test and a check for known high or critical vulnerabilities, stops at the first failure, and records the result.

  Live

• A security check of everything we run, every day

  Every day, every package that ships is checked against the public database of known vulnerabilities, and Node.js, Next.js, React and PostgreSQL against their support dates. Each finding gets the policy's deadline the day it is found, we are alerted, and the result is published on the status page.

  Live

• Development kept off the live database

  Development and testing run on their own database, which holds only test agencies and sample data. The live database is never used to build or try features.

  Live

• The same inspection for CVs your team uploads

  CVs your team adds in the admin will go through the same inspection as those candidates send.

  Due: Before the first live agency's candidate data

  In progress

• A script policy on every page

  Adds a Content-Security-Policy that lets only the site's own scripts run, using a fresh value for each page, as a second line of defence behind the cleaning above.

  Planned

• Independent penetration test

  A test of the web application and its interfaces by an outside firm, with its findings fixed and retested. Its summary will be in the security pack.

  Due: When an agency's security review needs one

  Planned

Limits that keep forms, inboxes and AI credits from being misused.

• Every public form has a platform-wide limit

  Applications, CV uploads, enquiries, alert sign-ups, sign-in codes and the site assistant are limited per address across every agency's site, and a visitor who hits one is told in their language how long to wait.

  Live

• No one can flood an inbox through a site

  An email address typed into any form receives at most a handful of emails a day across all sites, and fewer for alert confirmations. Applications are always saved, even when the receipt is held back.

  Live

• Hidden traps for automated form filling

  Public forms carry a hidden field people never see; a submission that fills it is answered quietly and goes nowhere.

  Live

• AI credits protected from draining

  The site assistant is limited per visitor address and per agency, and each turn reserves its credit before the model is called, so parallel requests can't spend past the balance.

  Live

• Bot detection on public forms

  Vercel BotID is running on public forms in observe mode. Once a week of results shows it doesn't turn away real candidates, it starts blocking.

  Due: November 2026

  In progress

How we find out something is wrong, before you have to tell us.

• Errors recorded and alerted, without personal data

  Every server error is recorded with the route's pattern, never the real address, and the operator is alerted. Logs drop database values and mask emails, phone numbers and tokens.

  Live

• Scheduled jobs watched, missed nights caught

  Every scheduled job records each run and reports failure loudly. A check every five minutes tests the database and notices a nightly job that didn't run.

  Live

• A public status page that leans against us

  airtasites.jp/status shows 90 days of checks for the sites, email delivery and scheduled jobs. A check that didn't run counts as failed, and days before monitoring began show as no data, never green.

  Live

Copies we can restore from, and proof that restoring works.

• Daily backups, kept up to 190 days

  The database is copied in full every day over a verified encrypted connection. Daily copies are kept 7 days, Monday copies 5 weeks and first-of-month copies 190 days, and each copy is checked to be complete before it is kept.

  Live

• Encrypted copies kept off-site

  Each day's backups are encrypted with AES-256 and copied to separate cloud storage, and every copy is reopened after upload to prove it restores.

  Live

• Restores tested, not assumed

  A backup is restored into a fresh database and compared with production table by table, at least once a quarter. The latest result is shown on this page.

  Live

• A written continuity and recovery plan

  Recovery objectives, and what we do about outages, data loss, a lost provider account, stolen credentials, a lost computer and our own unavailability, tested by the restore drills.

  Live

• A named person who can act if we can't

  A trusted person, named in our internal plan, holds sealed instructions to reach every agency, keep the service running and help each agency take its data and domain elsewhere.

  Due: November 2026

  In progress

• Point-in-time recovery

  Turns on continuous database backup, so data can be restored to any moment rather than to the last daily copy: from up to 24 hours of loss to minutes.

  Due: With the first paying agency

  Planned

• A second copy of uploaded files

  Images, CVs and recordings are stored in Vercel Blob, apart from the database, and aren't in the daily database backup. This adds an encrypted copy of them alongside it.

  Due: Before the first live agency's candidate data

  Planned

How long candidates' data is kept, how it leaves, and what happens in a breach.

• Applications deleted on your schedule

  Each agency sets how long applications are kept, by outcome, and they are deleted automatically when that time is up. The apply form's privacy notice states the period from the same setting, and a change never lengthens what an applicant was told.

  Live

• Deleted data leaves backups within 190 days

  Backups are never edited, so deleted data remains in older copies until they expire. The longest-kept copy is 190 days old, so every deletion has reached every backup by then.

  Live

• One person's data, found and acted on

  When a candidate asks to see or delete what an agency holds, Settings › Privacy finds everything about them in one place and acts on it.

  Live

• Nothing personal in notification emails

  Emails to your team carry a link into the admin, never an applicant's name, contact details, CV or what they wrote.

  Live

• Export your content, settings and applications

  Owners can download the site's content, settings and applications at any time, free.

  Live

• Full export and offboarding with a deletion record

  Extends the export to every record and file an agency has, and adds an offboarding routine that deletes everything at the end of a contract and gives the agency a record of it.

  Live

• Told within 48 hours of a breach

  If a leak, loss or damage affects candidates' data, we tell the agency within 48 hours and help with its report to the Personal Information Protection Commission and its notices to the people affected. It is a term of the contract.

  Live

• A written incident response plan

  Severity levels, who does what, the APPI reporting timeline, notice templates in English and Japanese, and a review after every incident.

  Live

• Registers kept only as long as the law requires

  The job, job-seeker and fee registers keep what Japan's Employment Security Act requires, for two years after each record ends, even after an application is anonymised or a person asks for deletion. Then the nightly job deletes it. No AI agent can read them.

  Due: December 2026

  In progress

• No personal data inside the deployed code

  Removes the contact details of prospective agencies' staff from the reference data shipped with the application, so personal data lives only in the database, where deletion reaches it.

  Due: Before the first live agency's candidate data

  In progress

What the agents and the site assistant may read, and what they never see.

• Every agent works at a data level you choose

  Agents work on public content, counts or redacted work history, at the level each one is given. Names, email addresses and phone numbers are never sent to the AI.

  Live

• Applicants' details off until your owner turns them on

  Applicants' work history reaches the AI only for the Researcher and the Candidate Assistant, and only after your owner switches it on and confirms your privacy notice covers it.

  Live

• Contact details removed before anything reaches the AI

  CVs lose names, contact lines, links, birth years and family details; visitors' messages and survey comments lose emails and phone numbers. This happens on our servers, before the text is sent.

  Live

• What the AI reads is never used to train it

  The AI is reached through Anthropic's commercial service, whose terms exclude using what we send to train its models. Matching uses embeddings computed on our own servers.

  Live

• Data levels enforced by database permissions

  Most agents already read through a database role limited to their level. This moves the remaining few onto it too, so the level is a permission and not only a rule in the code.

  Due: Before the first live agency's candidate data

  In progress

• Recordings kept out of speech model training

  Consultants' recordings go to ElevenLabs for captions. Its terms allow it to learn from what it receives unless the account opts out; this records our opt-out. Candidates' data never goes there.

  Due: November 2026

  In progress

Every company that processes data for the service, listed and kept in step with the code.

• Every sub-processor listed, with 30 days' notice of a new one

  airtasites.jp/subprocessors names each company, what it does, what it receives and where. We give 30 days' notice before adding one.

  Live

• The code can't reach an unlisted company

  Every outside service the servers call is registered and tied to a listed sub-processor, a service the agency connects, or public data. A new one fails the tests until it is listed.

  Live

• Services you connect, listed apart

  Your CRM, chat tools, webhooks, LINE, and the analytics and ad tags you add (Google Analytics, Tag Manager, ad pixels) are your own vendors, not ours. They are listed separately, and nothing goes to any of them until you connect or add it. Your site's privacy page names every tag you add.

  Live

• Suppliers reviewed every year

  Each sub-processor's security terms, breach notice terms, data location and published audits are reviewed once a year and when a contract changes, and what the review finds is acted on.

  Live

The computers and accounts that run the service, and the written rules behind them.

• Work computers fully encrypted

  The computers used to run the service have full-disk encryption on and lock their screens after five minutes.

  Live

• A written information security policy

  Access control, patching deadlines (critical within 72 hours, high within 14 days), change management, suppliers, devices and confidentiality, reviewed every year.

  Live

• Two-step sign-in on every operator account

  Two-step verification on every account that can reach the service: hosting, database, code, email and payments, with credentials kept in a password manager.

  Due: November 2026

  In progress

• Cyber insurance

  Insurance covering the costs of responding to a security incident.

  Planned