Privacy Policy — APC (Agent Profile Context)

Effective date

{{EFFECTIVE_DATE}}

Service

APC, at https://apc.abt.nz

Sign-in

handled by our own identity service at https://idp.abt.nz

Data controller

Andrei Shvechkov, an individual in New Zealand. APC is a project called ABT; ABT is not a company, and the controller is the named person

Contact

apc@abt.nz. A postal address is given on request to that address

Governing law

New Zealand

1. What this service is, in one paragraph

APC stores a small profile about you — a set of short statements such as what you do, how you prefer to work, what you are currently building — so that the AI agents you use can read it instead of asking you the same questions in every new conversation. Your agent connects to APC over the Model Context Protocol at a URL that identifies your profile. You sign in with your Google account; the sign-in itself is handled by our identity service at https://idp.abt.nz, which is part of the same service and run by the same operator as https://apc.abt.nz.

This policy covers both of those hosts.

2. Read this first: your profile is written by AI agents, not only by you

This is the most important thing to understand about APC, and it is unusual enough that we put it before the data inventory.

• Reading is automatic, and so is being admitted to read. Once an agent has been authorised for your profile's address at our identity service, the first request it makes admits it: the server writes it a grant carrying the reading permission and nothing else, without asking you. From then on it reads your whole profile at the start of a conversation without asking you each time. There is no per-agent visibility level — every agent connected to your profile sees everything in it.
• Writing is not automatic. You allow it, in a browser. A newly connected agent cannot write. The permission to write is added by you, signed in, on your own connection page at https://apc.abt.nz/connect/<your profile id>, where the agents connected to your profile are listed and you allow one of them by name.
• Once you have allowed it, no human is in the loop at any point. There is no queue, no review and no confirmation step. When an agent decides something about you is worth remembering, the statement is written into your profile immediately and is visible to every agent at once. Nobody — not us, not you — sees it first.
• A third permission, profile:approve, is your own oversight. It is what opens the journals described in 3.5 and what lets an agent undo a write. It is never granted by default, never included in "grant everything", and never handed out by connecting: today the only way to obtain it is a one-time pairing code minted at the console of our server with an explicit flag, which in practice means asking apc@abt.nz.
• Consequence: you may not know what an agent has recorded about you until you look. What is in the profile now is apc_get_facts and apc_search_facts, which any agent of yours can read. What was written, by which agent, when and on what stated grounds, is the write journal (apc_get_write_log); who read the profile is the read journal (apc_get_journal). Both journals need profile:approve, so an ordinary agent of yours cannot open either. The one signal that reaches an ordinary agent is a counter of writes you have not yet reviewed, carried in the profile's manifest — that counter is the only notification this service has, by design (see section 12).
• A write can be undone, for 30 days. Undoing a write retires the statement it added and restores whatever it replaced. An agent can do it only with profile:approve, and only for writes that agents made — your own statements, and anything in the constraints section, are refused. After 30 days the undo is no longer offered. This is a real remedy and a bounded one: it is not a general "delete this statement", and there is no such thing here. See section 7.
• Agents are not ours. The agent is software you chose, run by whoever you chose. We do not control what it decides to write about you, and we do not review it.

We do not filter what agents write for accuracy. APC checks the shape of a statement — its length, that it contains no URL, no markup, no invisible or look-alike characters, no instruction-like phrasing — and nothing about whether it is true, fair, or about you at all.

3. What we collect

3.1 From Google, when you sign in

Sign-in requests two non-sensitive Google scopes, profile and email. From the response we receive and store, in our identity service:

• your Google account identifier;
• your email address;
• your display name (and given/family name, where Google supplies them);
• the URL of your Google profile picture — we store the link, not a copy of the image;
• the raw response from Google, kept as-is, which includes the Google access token issued during sign-in.

We do not receive your Google password, your contacts, your mail, your files, your calendar, or anything else. Our identity software also sends one request to Google's People API for a phone number; because we do not request the corresponding permission, Google refuses it and no phone number is collected.

3.2 Your identity inside APC itself

The APC service proper stores exactly one thing about who you are: the pair (identity provider, subject identifier) — that is, "this profile belongs to subject <opaque id> at https://idp.abt.nz". There is no column for your name, your email or your IP address anywhere in the APC database.

When you sign in through a browser — to claim a profile, or to open your connection page — a short-lived row is written for that sign-in. It holds the same pair once the sign-in has succeeded, plus digests of the values we minted for it (the session cookie, the state, the nonce, the form token) and, for the few minutes between the redirect and your return, the PKCE verifier in the clear. These rows expire after 15 minutes and are deleted by the maintenance pass. They contain no name, no email address and no IP address either.

3.3 Your profile content

• Facts — the statements themselves: free text up to 300 characters each, plus a section, a language, timestamps, and whether it came from you, from an agent, or from an import. A copy of the text is kept in a search index, and a hash of the normalised text is kept for duplicate detection.
• Who wrote each statement — recorded on the statement itself: which agent's grant, and a snapshot of that agent's label, OAuth client identifier and subject as they stood at the moment of the write, plus the reason the agent gave for writing it. The snapshot is kept as well as the link so that revoking an agent later does not erase the authorship of what it wrote.
• Tags attached to facts, and links (URLs) attached to facts. URLs are not permitted inside the text of a statement and are stored separately.
• Supersession history — which statement replaced which.
• The write journal — one row for every write and every undo: which statement, which section, which agent, the reason it gave, when it happened, and whether it has since been undone and by which undo. This is what section 7 lets you read and act on.
• Profile metadata — the profile title, creation and claim timestamps, last activity timestamp, when you last reviewed the write journal, and a hash of the one-time claim link secret.

3.4 Agent access

For each agent connected to your profile: a label (chosen by you, or by whoever issued its pairing code, or set to self-admitted when the agent was admitted by simply arriving), the agent's subject and OAuth client identifier, the permissions it holds, the moment you allowed it to write if you did, and the times it was created, last used and revoked. Also a hash of any pairing code that has been issued.

3.5 The two journals and the usage counters

• Read journal — for every read: which agent, which tool, which sections, how many statements, and when. It contains no IP address — the table has no such column. Note that opening either journal is itself recorded here.
• Write journal — for every write and every undo: which statement and section, which agent, the reason it gave, when, and whether it has been undone. Its contents are listed in 3.3. One thing it deliberately does not show you is the text of a statement an agent can no longer read — one that a later write replaced, an undo retired, or whose expiry passed. The entry still stands and says which of those happened; the text itself is in the full export we run for you on request (section 7).
• Both journals take a separate permission. apc_get_journal and apc_get_write_log require profile:approve, which is never granted by default, never included when permissions are handed out in bulk, and never obtained by an agent simply connecting. Today the only way an agent can obtain it is a pairing code minted at the console of our server with an explicit flag, which in practice means asking apc@abt.nz. Until that is done, no agent of yours can open either journal.
• Daily counters — per day, how many reads and how many writes your profile saw, and the number of statements and characters it held at the end of the day.

3.6 IP addresses

We want to be precise here, because it is easy to overstate.

• Not in the APC database. No table in APC has an IP column. The counters that limit abuse (drafts per day, pairing-code guesses, browser sign-in attempts, metadata requests) are held in the memory of the running process only and are forgotten when it restarts.
• In server logs, yes. Our web front end and the APC application both write ordinary access logs to disk on our server. These contain your IP address, the host and path you requested (which includes your profile identifier), the response status and timing. The secret in a one-time claim link is deliberately stripped from both logs before writing.
• Retention of those logs is by size, not by age. Each service keeps up to 10 MB × 3 rotated files. There is no time limit, and deleting your profile does not remove anything from these logs.

3.7 Records held by our identity service

Our identity service (Casdoor, at https://idp.abt.nz) keeps its own records, separate from APC's database:

• your account record, with the fields listed in 3.1, plus the IP address you registered from, the IP address of your most recent sign-in, and the time of it;
• a password hash and salt — only if you set a local password there. Accounts created by signing in with Google have no password;
• the tokens it issues, stored in full: access tokens, refresh tokens, the authorization code and the requested permissions;
• an audit log of every POST request, including the client IP, the username, and the body of the request verbatim. For a Google sign-in that body contains the OAuth authorization code and the PKCE verifier. If anyone sets or changes a local password there, that password appears in this log unmasked.
• sign-in sessions.

None of these identity-service records currently has any retention limit, and none of them is removed when an APC profile is deleted. We consider the verbatim audit log a defect rather than a design choice; see section 9.

3.8 What your agent's token contains

The token our identity service issues to your agent is a signed JWT that carries, among other claims, your email address, display name and avatar URL. APC itself ignores those claims and stores none of them — it reads only the issuer, subject, client, token id, audience, expiry and permissions. But the token is handed to your agent, which means the provider of any agent you connect receives your email address. We cannot prevent this and we do not control what that provider does with it.

4. Why we process this, and on what basis

Where New Zealand requires consent rather than these bases, your consent is given by signing in and by choosing to connect an agent, and can be withdrawn as described in section 7.

We do not sell your data. We do not use it for advertising. We do not profile you for any purpose other than serving your own profile back to your own agents. Nothing stored here is used to train any model by us.

5. How long we keep it

These are the periods actually implemented in the running code, not aspirations.

6. Who else sees this data

• Google LLC — because you sign in with Google. Google learns that you signed in to this service and when. We receive from Google only what is listed in 3.1.
• Google (lh3.googleusercontent.com) — your profile picture is stored as a link to Google's servers. When a page displays it, your browser fetches it from Google, which lets Google see your IP address and browser at that moment.
• cdn.casbin.org — our identity service loads its front-end assets from this content delivery network, operated by the Casdoor project. Your browser contacts it while you are signing in, which exposes your IP address and browser to that operator. This is a default of the software we use that we have not yet overridden.
• The provider of any AI agent you connect — receives a token containing your email address, display name and avatar URL, and reads the contents of your profile. Which providers these are depends entirely on which agents you choose to connect; agents register themselves dynamically, so we cannot publish a list in advance.
• A commercial hosting provider, in the Netherlands — operates the physical machine and therefore has access to the disks holding the databases and logs. We name the category and the country here rather than the company; if you need the name, ask at apc@abt.nz and you will be told it.
• Let's Encrypt (ISRG), and ZeroSSL as a fallback — issue our TLS certificates. They receive our domain names, the server's IP address and our ACME contact address. Domain names issued a certificate appear permanently in public Certificate Transparency logs.
• Anyone with administrative access to our server — the operator, Andrei Shvechkov — can read the databases and the logs directly. There is no technical barrier between the operator and your profile content.

We do not otherwise disclose your data, except where we are legally required to.

7. Your rights, and how you can actually exercise them today

We list what the software does today, not what it should do. Where there is no self-service route, the honest answer is "write to us".

Limitation of profile deletion, stated plainly. Deleting a profile removes the profile row and, by database cascade, its facts, tags, links, supersession history, write journal, agent grants, read journal entries and usage counters. It does not remove: the account link recording that this identity provider subject used the service; anything held by our identity service (your email address, avatar link, registration and sign-in IP addresses, the stored Google token, issued tokens, audit records, sessions); or the server access logs containing your IP address and your profile identifier. If you ask us to erase your data, tell us so explicitly and we will remove those by hand as far as we are able — but the software does not do it for us today.

We aim to answer requests within 30 days.

8. Security — what is actually in place

• All traffic to both hosts is over HTTPS with certificates from Let's Encrypt.
• We never see or store your Google password. Sign-in uses OAuth with PKCE.
• APC never issues tokens or stores passwords itself; it only verifies tokens against the identity service's public keys.
• Each agent's token is bound to your specific profile; a token for one profile cannot read another. Requests for a profile the caller does not own return "not found", not "forbidden".
• Permissions are narrow by default. An agent admitted by simply connecting can read and nothing more; writing is added by you, in a browser you have signed in to; and profile:approve — the journals and the undo — is never granted automatically, in bulk, or by connecting.
• The pages you sign in to accept a submission only when your browser confirms it came from this site, and each form carries a token minted for the page it was rendered on. They load one stylesheet from this same site and nothing else at all — no script, no font, no image.
• One-time claim link secrets are stored only as hashes, and are stripped from all logs before they are written. So is the PKCE verifier of a sign-in in progress, which is deleted with the sign-in row.
• IP-based rate counters live in process memory and are never written to the database.
• The APC server makes no outbound requests while it is serving. At startup it fetches two documents from our own identity service — its OpenID configuration and its public signing keys — and caches them on disk. After that it talks to nothing outside our own machine, and your profile text is never sent anywhere.
• The sign-in page is a separate matter, and we would rather not blur the two. That page is served by our identity service, not by APC, and it is third-party software running close to its defaults: while you sign in, your browser loads its front-end assets from cdn.casbin.org, and any page that displays your avatar loads the image from Google's servers. Those requests are made by your browser, not by our server, and each one exposes your IP address and browser to that third party. See section 6.
• There are no backups of anything. A backup script exists in the project's source tree, but it is not installed on the machine that runs the service and has never run there: nothing is scheduled and no archive exists. If the disk or the database file is lost, every profile on it is gone. Do not let APC be the only copy of anything you care about.
• The database is a single SQLite file on our server, and its contents are not encrypted at rest beyond whatever the hosting provider's disk encryption gives us.
• This is a small, non-commercial service run by one operator. It has not undergone an external security audit or penetration test, and it carries no certification.

9. Known gaps we are not hiding

We would rather write these down than let you assume they do not exist.

1. Erasure is incomplete in code. As described in section 7, deleting a profile leaves the account link, the identity-service records and the server logs untouched.
2. Our identity service's audit log records request bodies verbatim, including the OAuth authorization code and PKCE verifier — and any local password, unmasked, if one is ever set. It has no retention limit. Only the operator can read this log, but that does not make it right, and reducing it is on our list.
3. Access logs hold IP addresses with no time limit — only size-based rotation.
4. Tokens issued to your agent contain your email address, and we cannot strip it.
5. No interface deletes an individual statement. A statement can be superseded, and a write can be undone for 30 days; neither removes the old text, which stays for a further 90 days.
6. APC does not detect personal data about other people in what an agent writes. Our rules forbid storing information about third parties in a profile, but that is an obligation on you and your agents, not a control the software enforces — it checks only the shape of the text.
7. Reading access is granted without asking you. Any client authorised for your profile's address at our identity service is admitted to read the profile on its first request. What protects you there is that the authorisation happened at all — it is a deliberate act you performed at the sign-in page — and not a second check by us. See section 2.
8. Every agent you connect sees the whole profile. There are no per-agent visibility levels and no way to hide part of a profile from one agent and not another.
9. An agent holding profile:approve can undo writes another agent made, not only its own, and undo them without asking you. That is deliberate — it is how you deal with an agent you no longer recognise — but it means that permission is the one to be careful with.
10. Both journals and the undo are out of reach with the permissions an agent gets by default. All three need profile:approve, which today is issued only at the server console.
11. There are no backups. No archive of your profile exists anywhere. See section 8.

10. Children

APC is not intended for anyone under 16, and we do not knowingly collect data from children. Sign-in requires a Google account. If you believe a child's data is held here, write to apc@abt.nz and we will delete it.

11. International transfers

Our server stands in the Netherlands, in a data centre run by a third-party hosting provider we do not name on this page. Signing in involves Google LLC, and certificate issuance involves Let's Encrypt (ISRG), both in the United States; the Casdoor content delivery network and the providers of the agents you connect may be anywhere. By using the service you accept that your data is processed in those places. Where New Zealand requires a specific transfer mechanism, Andrei Shvechkov, as the controller, is responsible for putting it in place.

12. Changes to this policy

If we change how we handle your data, we will update this page and change the effective date at the top. For a change that materially expands what we collect or who receives it, we will also place a notice on https://apc.abt.nz/. Because the service has no email channel to you by design — APC sends no email, no messages and no webhooks — this page is the only place changes are announced. Please check it if this matters to you.

13. Contact

Questions, access requests, corrections and deletion requests: apc@abt.nz.

Controller: Andrei Shvechkov — an individual in New Zealand, reachable at the address above; a postal address is given on request. If you are unhappy with our response and New Zealand gives you the right to complain to a supervisory authority, you may do so.

A Russian translation of this policy is available at https://apc.abt.nz/ru/privacy. If the two versions differ, this English version governs.