Data access
Gold Standard.

Result

The access job is to commission a source connection, not to collect a key. For every service, the complete unit is:

source + principal + authority + grant + credential custody + connector + live-data evidence

The complete eleven-source estate is 6 with a usable read path / 5 blocked or gapped. Under the stricter personnel-independent and repeatable-access durability test, it is 2 durable / 9 needing work. A received export may be a durable artifact without being a durable refreshable connection; Slack is classified that way below.

The eleven sources do not all have the same repair:

• Role or report entitlement, not a new key: impact.com, ClickUp.
• Documented credential or API contract required before another probe: RichAds, Mysterium, GoProxies.
• Working now; complete source mapping and operational hardening: Grafana, CJ, Omnisend, Ahrefs, BigQuery, Slack.

No credential value belongs in this note, the vault, Kairos Git, an email, or an agent message.

Full-estate access and durability denominator

Usable means a current path can return business data inside its recorded boundary. Durable additionally means the access is organization-controlled, repeatable and does not ordinarily fail when one person's account, employment or session changes. Every classification below links to the evidence that supports it; unknown ownership or recovery fails closed to needs work.

The count is therefore six usable sources (BigQuery, Slack, Grafana, CJ, Omnisend campaigns and Ahrefs), five blocked or gapped sources (impact.com, RichAds, Mysterium API, GoProxies and ClickUp), and two durable identities (impact.com and Grafana). Durability never overrides a failed access or source gate: impact.com remains gapped despite its durable principal.

What “gold standard” means

A connection reaches Gold only when all of the following are true:

1. Authorized: the named source owner has approved the source, purpose, and data perimeter.
2. Organization-controlled: a vendor-supported service or role identity is preferred over a person-bound token. The identity survives ordinary personnel changes without sharing one person's login.
3. Vendor-enforced read-only: the credential cannot write, delete, spend, manage users, change security policy, or administer billing. Client-side GET allowlists are compensating controls, not vendor-enforced read-only.
4. Least privilege with enough coverage: broad enough to answer the named Kairos questions, but no broader than the lawful read need.
5. Revocable and rotatable: owner, expiry, rotation owner, revocation path, offboarding path, and emergency replacement are recorded.
6. Auditable: the service identity, connector, account/workspace, permission set, last successful use, rate/cost ceiling, and failures are attributable.
7. Proven against real data: a business-relevant fixture returns a measured denominator and non-empty required fields. Authentication alone never passes.
8. Commissioned: reachable objects, history, schema, refresh cadence, exclusions, join keys, metric definitions, and drift triggers are inventoried.

Second best is the strongest vendor-supported path that remains authorized, revocable, repeatable, and accepted against real data. It must name the missing Gold property and the compensating control. If no safe repeatable API path exists, the fallback is a controlled export, not an improvised credential probe.

One packet MN should provide for every connection

The credential travels through the approved secret channel. Separately, the source owner returns this metadata-only packet:

Allowed return states are GRANTED, PARTIAL, NOT POSSIBLE, or NEEDS OWNER. “Key sent” is not a completion state.

Priority and concurrency

Keep no more than three access acquisitions in flight:

1. Wave 1: impact.com, ClickUp, GoProxies.
2. Wave 2: RichAds, Mysterium, CJ/Ahrefs durability hardening.
3. Wave 3: Grafana and Omnisend commissioning gaps.

impact.com is the highest-value unblock. ClickUp is the cheapest measured fix. GoProxies is ahead of RichAds and Mysterium because its official authentication and statistics contract is now documented and the current funnel question is already defined.

1. impact.com

Current evidence: the scoped token authenticates, lists reports, and runs them, but July 2026 and the November 2024 control return empty metric cells. One action-listing endpoint returns 403. This is an access defect, not evidence that the program has no data.

Gold target

An organization-controlled scoped token for the MN advertiser account and Mysterium VPN program, with only the exact read methods required for:

• report listing and metadata;
• GET/report execution for action, performance, commission and finance data needed by the affiliate-to-warehouse reconciliation;
• asynchronous Jobs reads when a report requires them;
• the full required date horizon and stable order/action/partner identifiers.

Keep the existing role identity if it is organization-controlled. Do not rotate the token merely because the underlying report entitlement is wrong.

MN-side steps

1. An impact.com account administrator opens the current token and the underlying advertiser user's/report permissions.
2. Confirm which exact report IDs are ApiAccessible: true; retrieve each report's metadata and required fields.
3. Add the missing report-data entitlement to the account/user and only the required GET report scopes to the token. Exclude POST, PUT, DELETE, billing, user management and campaign mutation.
4. Name an MN technical contact and record quarterly rotation, revocation, API version and rate-limit ownership.
5. Return GRANTED only after the acceptance fixture passes.

impact.com supports fine-grained scoped tokens and recommends selecting only the needed APIs and HTTP methods, naming a technical contact, monitoring usage, and regular rotation: Scoped Tokens: Best Practices.

Second best if API report data cannot be granted

Schedule the same complete report as CSV with metadata to an MN-controlled SFTP destination. Hosted SFTP is preferable to email. Fix the report ID, filters, account/program, currency, time zone, date window and delivery cadence. Configure the schedule to deliver an explicit empty file when there is no data so “no activity” remains distinguishable from “delivery failed.” impact.com documents email, FTP and hosted SFTP scheduling: Schedule Reports.

Acceptance fixture

• Run one closed month with known activity: July 2026.
• Run the November 2024 control.
• Require non-empty metric cells, required identity and currency fields, report metadata, all pages/jobs complete, and a recorded row denominator.
• Reconcile at least one returned action/order to the impact.com UI or scheduled export and then to the warehouse without recording customer identifiers here.

Pass state: ACCESS_READY; next state: inventory every accessible report, field, history limit, pagination rule and refresh contract.

2. ClickUp

Current evidence: Lee's token authenticates. The Guest seat sees one List and zero of thirteen Spaces. Live UI evidence on 2026-08-26 established that Guests cannot receive Space shares, free view-only Limited Members can, and Šaras lacks the admin permission required to convert Lee.

Gold target

If ClickUp and MN policy explicitly permit an organization-controlled integration identity, use that identity as Limited Member View Only / Chat Collaborator, share exactly all thirteen authorized Spaces, and authorize a dedicated OAuth integration. The Workspace owner/admin owns recovery and revocation. No edit, comment, member, admin, billing or user-management permission.

ClickUp documents personal tokens and OAuth as its two API authentication modes; only owners/admins can create OAuth apps: Authentication.

MN-side steps now

1. An MN ClickUp Workspace owner or admin opens People / Manage people.
2. Convert me@leematulis.com from Guest to Limited Member View Only / Chat Collaborator. Keep the role free and view-only.
3. Share all thirteen authorized Spaces to that identity with View Only access. Guests cannot receive Spaces; limited members can: Invite people to your Workspace.
4. Keep the current personal token in the approved local secret store until an approved organizational identity/OAuth replacement exists. Do not regenerate it during the role repair.
5. Record two Workspace admins who can repeat or revoke the grant.

Second best if an organizational identity is not vendor/policy-supported

Keep Lee's named account as the auditable principal, Limited Member View Only, with the personal token. Personal tokens do not expire, so rotate on a fixed calendar and immediately on suspected exposure, role change, or account removal. Document the admin replacement path. This remains person-bound, but the access itself is vendor-enforced view-only.

Acceptance fixture

• Get Authorized Workspaces returns the intended MN workspace only.
• Enumerate active and archived Spaces and prove 13 of 13 expected Spaces, plus the existing shared List where applicable.
• For each Space, enumerate Folder/List/task metadata and confirm read succeeds.
• Attempt no write. Verify the role from UI/API metadata and record explicit exclusions.
• Repeat after one hour or a new token session to rule out stale UI state.

Pass state: ACCESS_READY; then inventory the full Space/List hierarchy, date horizon, statuses, custom fields, owners, event timestamps and refresh method.

3. GoProxies

Current evidence: the two corrected 75-character values did not authenticate on the probed surfaces. The public contract now shows that the reseller API uses username/password login to obtain a bearer token; a bare “API key” is not the documented reporting credential.

Gold target

Ask GoProxies/MN for a dedicated organization-controlled reporting-only reseller identity that can authenticate through the documented login flow and is vendor-restricted to read statistics and list account/subuser metadata. Request:

• production base URL and API version;
• reseller username and secret delivered through the secret channel;
• GET-only access to traffic/request/country statistics and read-only subuser inventory;
• account denominator, history, rate limits, expiry, rotation and revocation;
• explicit confirmation that subuser creation, reset, enable/disable and deletion are denied.

The documented flow is POST /api/v1/login to obtain a bearer token, followed by statistics reads such as GET /api/v1/stats/traffic: GoProxies Statistics.

Do not try the current unidentified values as usernames, passwords, proxy secrets or bearer tokens until the issuer identifies them.

Second best if GoProxies cannot issue a read-only identity

Use a dedicated MN-controlled reseller credential with no human dashboard reuse, stored in the approved secret store, and put a narrow connector in front of it:

• outbound host allowlist: api.goproxies.com only;
• login plus GET /api/v1/stats/* and required read-only list endpoints only;
• block POST/PUT/DELETE after login in code and egress policy;
• log endpoint, account, window, result count and HTTP status without secrets or customer identifiers;
• rotate on a fixed schedule and whenever the custodian changes.

This is not vendor-enforced read-only: the public reseller bearer also covers mutating subuser endpoints. Record that residual risk. If MN will not accept it, use a recurring dashboard/export file containing the same aggregate metrics.

Acceptance fixture

• Authenticate through the documented login flow.
• Pull one closed seven-day window of traffic and request-history aggregates.
• Return non-empty fields, countries, units, time zone, account/subuser denominator and full pagination.
• Cross-check the aggregate against the GoProxies dashboard for the same window.
• Confirm all mutation tests are denied by vendor scope for Gold, or blocked by the compensating connector for the fallback.

Pass state: ACCESS_READY; then map traffic/request grain, plan/customer identity, history, revenue or billing linkage, and the conversion-value join needed by the GoProxies funnel analysis.

4. RichAds

Current evidence: a key exists, but the advertiser reporting base URL, authentication header/flow, scope and read-only probe are absent. RichAds' public site advertises API integration, while the current public documentation exposes publisher/SSP and conversion-postback material rather than a complete advertiser reporting API contract.

Gold target

Obtain an official advertiser-reporting onboarding pack from the account manager inside the authenticated RichAds dashboard or another verified official channel. It must contain:

• production and test base URLs, API version and OpenAPI/specification;
• exact auth scheme/header, account/advertiser ID and credential type;
• vendor-enforced GET-only reporting scope;
• campaign, creative, spend, impression, click, conversion and cost fields;
• stable campaign/click/conversion IDs, currency and time zone;
• history, pagination, rate limits, errors, expiry, rotation and revocation;
• one harmless account/report endpoint and expected response shape.

Verify the representative through the authenticated platform. RichAds itself warns users to use its official sites and account dashboard when validating contacts: Official RichAds resources.

MN-side steps

1. Ask the verified RichAds account manager for the packet above and a dedicated organization-controlled reporting credential.
2. Require the manager to state whether the supplied key is production/test, advertiser/publisher, read/write, account-bound, expiring and revocable.
3. Deliver the secret separately; return only metadata in the access packet.
4. Build no connector and run no endpoint guesses until the contract is complete.

Second best if no reporting API exists for this account

Create a fixed recurring advertiser report in the RichAds UI and export CSV to an MN-controlled secure store. If scheduling is unavailable, assign a named MN owner to produce a monthly locked export. Fix the account, campaign denominator, columns, currency, time zone, attribution window and “no data” behavior. Hash and manifest each delivery so missing files and changed schemas fail visibly.

Acceptance fixture

• Pull/export one known active closed seven-day period.
• Require non-zero spend or delivery metrics, complete campaign denominator, stable IDs, currency, time zone and explicit pagination/completeness.
• Reconcile totals to the RichAds UI for the same filters and timestamp.
• Prove the credential cannot create, edit, start, stop or fund a campaign.

5. Mysterium API

Current evidence: the delivered value's service identity drifted during handoff and all attempted documented/guessed auth shapes returned 401/404. No public Mysterium reporting contract was found that safely identifies the intended 75-character credential. Public TequilAPI documentation is a node-management surface and must not be substituted for an unknown MN business API.

Gold target

The original issuer must identify the connection before reissue:

• exact product/service and business purpose;
• production base URL, API version and official/internal specification;
• principal/account/entity represented by the credential;
• auth scheme and credential type;
• vendor-enforced read-only scopes, objects, fields and history;
• expiry, rotation, revocation, rate/cost limits and technical owner;
• one real-data acceptance fixture tied to a named Kairos question.

Then issue a new organization-controlled service credential with read-only telemetry/reporting scope. Revoke the ambiguous old value after the replacement passes; do not destroy the only candidate before the new path is accepted.

Second best if the intended API cannot support scoped read-only access

Provide a source-owned recurring export or read replica containing only the authorized aggregate/account-level fields needed for the named question. Fix the schema, history, time zone, entity, denominator, refresh cadence and immutable delivery manifest. If the source owner cannot identify the original API at all, classify the old value UNKNOWN CREDENTIAL — DO NOT USE and re-open the access request from the business question rather than trying more endpoints.

Acceptance fixture

• The issuer-provided endpoint returns the intended account/entity and a measured real-object denominator.
• One closed seven-day aggregate returns non-empty required measures and stable IDs suitable for a documented join or explicit no-key result.
• The fixture records scope, exclusions, timestamp, pagination, freshness and expected empty-data behavior.
• All write/admin/billing operations are vendor-denied for Gold.

6. Grafana / VictoriaMetrics

Current evidence: a Viewer service-account token returns dashboards and PromQL data. More than 100 dashboards and 23 data sources are visible; ownership, retention and full metric coverage remain unmeasured.

Gold target

Keep a dedicated Grafana service account, not a human token. Use one token per Kairos connector, Viewer/read permissions only, a short explicit expiry, named rotation owner and separate revocation. Inventory its effective permissions with GET /api/access-control/user/permissions.

Grafana states that service accounts are not tied to a user, support multiple separately auditable tokens, and can be disabled independently: Service accounts.

On Enterprise/Cloud, apply data-source/folder RBAC to the authorized perimeter. On the current OSS instance, document that basic Viewer access is coarser and may query all data sources in the organization.

Second best if granular RBAC is unavailable on MN's Grafana tier

Keep the current Viewer service account but isolate the connector, allowlist the approved dashboard/data-source UIDs and PromQL query shapes, deny all write paths, and log aggregate query receipts. If the residual all-data-source query right is unacceptable, create a dedicated Grafana organization or a read-only metrics proxy exposing only the approved series.

Acceptance fixture

• Enumerate effective permissions, all visible dashboards/folders and data sources.
• Run one known dashboard query and one direct PromQL query over a fixed window.
• Record series count, labels, time range, freshness and response completeness.
• Confirm all dashboard/data-source/alert write operations are denied.
• Rotate to a second token without downtime, then revoke the first.

Pass state already reached: ACCESS_READY. Remaining work is source commissioning, not another access request.

7. CJ

Current evidence: the PAT works and a complete July advertiser commission set was pulled. Official CJ authentication is explicitly a Personal Access Token; legacy developer keys are deprecated. Personnel independence is therefore not a documented native property.

Gold target

Ask CJ support whether an organization-controlled integration login is permitted for MN's advertiser account. If CJ confirms it, create the PAT under that identity, bind it only to the required advertiser CID(s), keep it in the secret store, and record the MN owner, revocation and replacement path. Do not create a fictitious person or share a human login without vendor approval.

CJ documents bearer PAT authentication and deprecates developer keys: Authentication Overview.

Second best if CJ supports personal identities only

Keep a PAT owned by a named accountable MN user on a corporate email. The token is not shared between people; the connector reads it from the secret store. Record a second administrator who can issue a replacement, rotate on a fixed schedule and on offboarding, and test replacement before revoking the old PAT.

Acceptance fixture

• Pull one closed posting month for the intended advertiser CID.
• Follow cursor pagination until payloadComplete: true; never accept the first page as the denominator.
• Record count, posting window and stable orderId/commissionId shape.
• Combine original and correction delta records before comparing totals.
• Reconcile the full closed-month denominator to the CJ UI and the warehouse.

CJ's current Commission Detail API documents the endpoint, 31-day query windows, 10,000-record pages, cursor completion and correction semantics: Commission Detail API.

Pass state already reached: ACCESS_READY, hardening flag.

8. Omnisend

Current evidence: a Campaigns-scoped API key works. Orders return 403, but MN reports that orders are not stored in Omnisend; their actual “Data Studio” source must be discovered separately.

Gold target

Use a dedicated organization/store-controlled key named for the Kairos reporting connector, with Campaigns only and no Contacts, Orders, Products, Carts or Events permission unless a future named question requires them. Create a separate key per connector so each can be revoked without disrupting other integrations. Record the brand/store perimeter, creator role, rotation and revocation owner.

Omnisend documents per-key data permissions, multiple separate keys and deletion as revocation: Generate an API Key.

Because the vendor's Campaigns permission is resource-level rather than proven GET-only, the connector must still enforce reporting endpoints and methods only.

Second best if API permissions are too coarse

Use an Omnisend Analyst user for scheduled/manual report exports into the secure source store. Analysts can access reports and exports without campaign sending. Do not widen to Orders: discover the real upstream Data Studio source as a separate connection.

Acceptance fixture

• Enumerate accessible campaigns, report types and date horizon.
• Pull one known sent campaign's aggregate delivery/open/click/unsubscribe report and reconcile it to the UI.
• Record brand/store, campaign denominator, time zone, freshness and pagination.
• Prove Contacts, Orders, Products, Carts and Events remain inaccessible.

Pass state already reached: ACCESS_READY for campaigns; mapping remains open.

9. Ahrefs

Current evidence: API v3 responds. Ownership is unresolved. Ahrefs documents that only workspace owners/admins can create keys, each key expires after one year, and removal of the creating user invalidates the key.

Gold target

Ask Ahrefs support whether an organization-controlled integration identity is allowed. If yes, create the key under that approved workspace admin identity. Set a key-specific API-unit ceiling, disable or cap pay-as-you-go exposure, record the exact one-year expiry, and limit the connector to the required read reports, fields and rows.

Ahrefs documents creator dependency, expiry and per-key usage controls: API keys creation and management.

Second best if Ahrefs remains person-bound

Use a key created by a named MN workspace owner/admin on a corporate identity. Record a second owner/admin who can replace it. Rotate at least 30 days before expiry and immediately before creator removal. Put an alert on expiry and unit consumption; replacement must pass before the prior key is revoked.

Acceptance fixture

• Call the limits-and-usage endpoint and record remaining units and plan limits.
• Enumerate the accessible workspace projects/reports.
• Run one minimal-field, minimal-row business query for the agreed MN domain and record response date/index, row count and actual unit consumption.
• Confirm the intended history window and every excluded product/report family.
• Test the unit ceiling without causing pay-as-you-go spend.

Ahrefs currently documents a 60-request/minute default and a 50-unit minimum on most paid requests: API v3 Introduction.

Pass state already reached: ACCESS_READY, hardening flag.

10. BigQuery mysterium-bq

Current evidence: BigQuery returns live data through Šaras's Workspace-bound principal. The warehouse audit covered the full reachable schema denominator and bounded table fitness, but the credential repeatedly requires Šaras's session reauthentication. The audit's coverage receipt is evidence about the warehouse; it is not evidence of a durable principal or universal analytical fitness.

Gold target

Create an MN-controlled service account or approved external Google principal for Kairos with the broadest lawful read perimeter required for the named work:

• dataset/table/view metadata and data reads across the authorized warehouse;
• BigQuery job creation under the Kairos billing project;
• organization-approved job metadata visibility, including bigquery.jobs.listAll only when MN authorizes that audit need;
• no dataset, table, IAM, reservation, billing, policy or administrator writes;
• explicit project, dataset, location, row/column-policy and external-connection boundaries;
• two administrators, revocation, offboarding, emergency replacement and a rehearsed rotation path.

The maximum lawful perimeter must be evidenced by IAM role enumeration plus effective dataset/table policy checks. A successful query under the borrowed principal cannot establish what the durable replacement can see.

Second best until a durable principal exists

Keep the borrowed principal explicitly classified BORROWED_PRINCIPAL. Use it only inside the approved read/query contract, preserve query/job receipts, and record each reauthentication dependency. It may support bounded analysis, but it cannot mint fully_onboarded or Gold.

Acceptance fixture

• Assert the intended project, principal and location before the data read.
• Enumerate every authorized dataset and object family, including hidden or policy-restricted states, against an independently evidenced denominator.
• Run one metadata fixture and one known business-data fixture with complete job receipts and expected counts.
• Prove table/dataset/IAM mutations are denied by the vendor role.
• Compare the new principal's reachable fingerprint to the accepted baseline; any unexplained difference reopens scope and inventory.

Pass state now: ACCESS_READY_WITH_CONDITIONS, BORROWED_PRINCIPAL, MAPPING_PARTIAL; Gold remains open.

11. Slack public-channel export

Current evidence: the received archive passed ZIP CRC and all 36,247 embedded manifest size/hash checks. It contains 237 public-channel directories, 292 user profiles and 36,240 dated channel JSON files from 2017-10-19 through 2026-08-18. The export has no standard DM, MPDM or private-channel manifests. Structural inventory is complete for the artifact; semantic message coverage is partial and live-workspace completeness is unknown. Evidence: [[Metis Slack export delivery report — 2026-08-24]].

Gold target

If MN authorizes repeatable Slack access, use a source-owner-controlled export or vendor-supported read integration whose principal, channel perimeter, retention, hidden/private states, pagination, rate limits, expiry, revocation and refresh owner are explicit. The connection must distinguish:

• the live workspace denominator from the delivered-export denominator;
• public, private, DM, MPDM, canvas, thread, edit/delete and file surfaces;
• bot/alert volume from human conversation;
• mechanically examined files from semantically examined messages;
• personal-data handling from aggregate analytical output.

No request should widen the current public-channel authority by implication. Private or direct-message surfaces remain excluded unless MN provides exact authority for them.

Second best while the source is a bounded export

Keep the immutable received archive and its integrity manifest as a controlled snapshot. Record the fixed end date, explicit missing surfaces and every analysis denominator. A new export is a new acceptance event: hash, manifest, structural inventory and drift comparison must pass before it replaces the baseline.

Acceptance fixture

• Verify the outer file, ZIP CRC and embedded manifest against the accepted baseline.
• Reconcile channel directories one-to-one with channels.json and all declared payload files to the embedded manifest.
• Record the delivered channel/file/message denominator, date horizon, excluded surfaces and untouched semantic remainder.
• Run one intended-use fitness fixture that separates automated alerts from human text and returns aggregate metadata only.
• On refresh, fingerprint schema, channel set, horizon and denominators; any unexplained change becomes MAPPING_DRIFTED.

Pass state now: ACCESS_READY_WITH_CONDITIONS, EXPORT_SNAPSHOT, MAPPING_PARTIAL; Gold remains open until a repeatable authorized refresh path exists.

Completion and monitoring

Vault-backed evidence is part of completion

Every data-access probe, credential check, source dive, audit, inventory, map, fitness run, lineage finding, acceptance fixture and drift check must be saved before the step is called complete. Chat text, terminal output and an agent's working context are not durable evidence.

The minimum durable save is:

1. a vault receipt or update to the source's existing vault orientation note, stating the timestamp, principal class, exact denominator, examined and untouched coverage, result state, failures, unknowns and reopen condition;
2. exact pointers to the raw or machine-readable artifacts in their authorized store, including stable hashes or job IDs where available;
3. a Source Atlas update when the Atlas target is available, without replacing the source-specific receipt;
4. the normal vault log entry for every created or substantively edited note.

If a source changes, append or create a dated refresh receipt and diff it against the accepted baseline. Re-run because freshness or drift requires it, never because the prior work existed only in chat and was lost.

For each service, completion requires all of these receipts:

1. metadata-only access packet;
2. source-access gate state ACCESS_READY;
3. real-data acceptance fixture;
4. full reachable-universe inventory with explicit exclusions;
5. first-use fitness contract;
6. Source Atlas update;
7. credential-expiry and last-success monitor;
8. rotation rehearsal or controlled-export failure test.

Reopen access certification after any auth failure, rotation, role/scope change, principal removal, account/workspace change, empty or partial fixture, or silent denominator drift. Reopen source commissioning after schema, history, metric, refresh or join-key drift.

Current execution owners

The Kairos side accepts or rejects the connection; it does not ask MN to certify its own work without a live fixture.