Security at MapKraken

Territory Mapper is a territory-management application for Salesforce, published by MapKraken Labs LLC.

This page describes how Territory Mapper handles your data, what it stores, what it does not, and which security controls are in place today. It is written to be checked. Where a control does not exist, this page says so rather than implying otherwise — there is a section for exactly that, and it is not short.

Territory Mapper is pre-release. It is not yet listed on the Salesforce AppExchange and has no production subscribers. Several of the controls an enterprise security team expects are in progress rather than in place, and they are listed in What we do not claim yet. We would rather you read that section first than find it later.

---

1. Architecture

Territory Mapper has three tiers.

A managed package installs in your Salesforce org and holds the territory model, the assignment logic and the administrative setup. A map application — a browser application served from a content delivery network — runs inside your Salesforce org in a Canvas frame. A geospatial service, hosted by MapKraken on Amazon Web Services, performs the spatial work: turning a set of selected census boundaries into a dissolved territory polygon, and answering the map's queries about geography.

Your CRM records stay in Salesforce. The geospatial service holds census geography — public reference data — together with the identifiers and territory names it needs to associate a polygon with one of your territories. Section 2 lists exactly which.

   ┌─ your Salesforce org ─────────────────────────────┐
   │                                                   │
   │   Territory Mapper managed package                │
   │   territory model · assignment · setup            │
   │                                                   │
   │   ┌─ Canvas frame ────────────────┐               │
   │   │   the map application         │               │
   │   └───────────┬───────────────────┘               │
   └───────────────┼───────────────────────────────────┘
                   │
        signed handshake, verified server-side
                   │
                   ▼
   ┌─ MapKraken geospatial service (AWS, us-east-1) ───┐
   │                                                   │
   │   spatial operations · territory geometry         │
   │   census geography (public reference data)        │
   │                                                   │
   └───────────────────────────────────────────────────┘

Two directions of traffic are worth naming, because a security team will ask about both. The map application reads and writes your Salesforce data as the signed-in user, over Salesforce's own APIs, with that user's field-level security and sharing rules enforced by the platform. Separately, the geospatial service reads your territory hierarchy back from Salesforce using a per-org credential your administrator authorises at install.

---

2. What we store — and what we do not

The geospatial service persists eight things. This is the complete list, read from the running database rather than from a design document.

What is not stored, stated as specifically as we can make it. We checked every column of every table, not our expectations:

• No account, contact or lead records. No CRM object name is held in any column.
• No addresses. There is no street, city, postal-code or formatted-address column anywhere.
• No geocoded locations of your records. Territory Mapper's assignment path geocodes an account inside Salesforce and uses the result to ask the service which territory contains this point. The point is never sent to the service and never stored. There is no point geometry in the database at all — only polygons.
• No Salesforce user Ids. The geospatial service reads no user identity.
• No Salesforce session ids. Nothing carries one anywhere, on any hop.

Territory names are free text that you control. They are stored exactly as entered and are not inspected or validated. If you put personal information in a territory name, it will be persisted. We mention this because it is the one field on the list where what gets stored is your choice rather than ours.

How long we keep it. See §7. The honest answer is short and it is not the one you want.

---

3. Tenant isolation

Each subscriber org's territory data is held in a separate set of database tables, partitioned by your Salesforce Org Id. On every data route, the org identity used to select those tables is taken from a cryptographically verified token and never from anything the caller supplies; a request that names one org while carrying a token for another is rejected, not served.

The partition is enforced in the application layer. It is not enforced by the database itself: there is no row-level security and no per-org database role. We state this plainly because a security team will find it, and because "application-layer" is a materially different guarantee from "database-enforced."

We do not yet claim complete tenant isolation. One isolation defect is open and tracked, identified by our own security review: the token the Salesforce side presents to the geospatial service is signed with one shared secret rather than a per-subscriber key. That means the service can verify that a token is genuine, but not that it belongs to the subscriber it names. (A second defect, an unauthenticated path to the same outcome, was found in the same review and closed on 2026-08-19.)

So the service is operated for a single subscriber, and this is enforced, not merely intended. The credential table carries a constraint that makes a second active subscriber credential impossible to insert; onboarding a second organisation fails at the database, by design, until per-org signing keys ship. That work is designed and scheduled to the day it is first needed. The full position, including the wording we give a security reviewer, is written down and we will share it on request. See also What we do not claim yet.

---

4. Encryption

In transit.

• Traffic between your browser and Salesforce, and between the map application and Salesforce's APIs, is HTTPS, terminated by Salesforce.
• The geospatial service reads your Salesforce hierarchy over HTTPS.
• The service connects to its database over TLS 1.3 (TLS_AES_256_GCM_SHA384). This is what the application does; it is not currently enforced by the database server, and we say so rather than let the stronger reading stand.

We do not claim that all traffic to the geospatial service is HTTPS. The service currently answers over cleartext HTTP as well as HTTPS. Enforcing HTTPS-only is planned. This is listed in What we do not claim yet and it is one of the items we consider blocking for general availability.

At rest.

• Secrets are held in AWS Secrets Manager, encrypted with AWS-managed keys (§6).
• The census geography served as map tiles is public reference data from the U.S. Census Bureau. It contains no subscriber content.

The service database is not encrypted at rest. Migrating it to an encrypted volume is planned and scoped; it cannot be enabled in place, which is why it is the longest-lead item on our remediation list rather than a configuration change. Stated plainly here because there is no honest way to imply otherwise.

---

5. Authentication and access control

How a request is proven to come from your org.

The map application is launched by Salesforce inside a Canvas frame. Salesforce signs the launch payload, and the geospatial service verifies that signature server-side — checking the signature itself with a constant-time comparison, pinning the signing algorithm, and rejecting a payload outside a five-minute window. Your org's identity is read from the verified payload and carried through to the database table name; it is never read from caller-supplied input on a data route.

Every data route on the geospatial service requires a verified bearer token. A request without one is refused. Cross-origin policy is not the control and is not relied on as one.

No token, org identifier or territory data travels in a URL on any hop. They travel in signed payloads and request bodies, so they do not land in browser history, referrer headers or access logs.

What runs as you, and what does not.

• Writes to Salesforce run as the signed-in user, with field-level security and sharing rules enforced by the platform. This is the most strongly enforced surface in the product.
• Every REST entry point in the managed package is gated by a custom permission at runtime, with a read/write split — not by profile, and not by assumption.
• The hierarchy read-back does not run as you. When the geospatial service reads your territory model back from Salesforce, it runs as the integration user your administrator authorised, in system field context rather than the viewing user's. This is deliberate — the map needs the whole model to draw it — and it is compensated by the custom-permission gate on the entry points and by sharing enforcement on every write. We state it rather than leave it to be discovered.

Authorization at the geospatial service is per-org, not per-user. A session token proves which org a request belongs to. It does not carry the user's Territory Mapper permissions, so inside the map, the service does not distinguish a read-tier user from a manager. Capability is governed by Salesforce permissions on the Salesforce side and by org scope on the map side. Adding per-user authorization to the service is planned. If per-user enforcement inside the map is a requirement for you, it is not there today.

Session lifetime. A map session lasts 8 hours and does not refresh.

---

6. Secrets and key management

Credentials used by the geospatial service are held in AWS Secrets Manager and supplied to the service at container start by the AWS platform. The application process itself holds no permission to read Secrets Manager at runtime.

Secret injection is the delivery path, and we have proved it is load-bearing — an end-to-end test completes a Canvas login on an image that has nothing to fall back on. On 2026-08-08 we inspected a container image directly and confirmed it carried no environment file, no private key material, and a clean result from a secret scanner run across the whole application directory.

We do not claim that the image running today carries no embedded credentials. Re-inspecting our registry on 2026-08-20, we found that our image build had begun including an environment file again after that clean build, and that the images now running include one. We found this ourselves, we are stating it rather than waiting until it was fixed, and correcting the build is our highest-priority open item. Two things a security team should weigh alongside it: the credentials involved are the ones already covered by our written credential-exposure disclosure, and nothing automatically detected the regression — which is the more important finding, and is why image scanning is now on the list in What we do not claim yet.

Source-history secret scanning. A full-history scan of all four of our repositories with gitleaks 8.30.1 on 2026-08-06 produced seven hits: two false positives, one already redacted, and four in deleted or superseded files. No live credential is exposed by our source history. The tool version and the exact command are recorded so the result can be reproduced rather than taken on trust.

We do not operate automated secret rotation. Rotation is manual today. Automating it is planned.

---

7. Logging and retention

Application logs. The geospatial service writes application logs to Amazon CloudWatch with a thirty-day retention period. Every log group in our hosting account carries an explicit retention period and none is unbounded. Sampling found operational events and no personal data; we have not completed a formal audit of log contents and do not claim one.

The Salesforce-side failure log. Territory Mapper records assignment failures in your org so they can be worked rather than lost. That log has a real, enforced policy:

• A failure record is purged 90 days after it is closed — the clock runs from the day someone finished with it, not from the day it was created.
• An open record is never deleted, at any age. Deleting one would silently un-report a failure that is still true.
• The purge is permanent and unrecoverable — not a recycle bin. (A platform-level tombstone remains visible to Salesforce's own deleted-records view for the platform's own window; no application can shorten that, and we will not claim that no trace remains.)
• It is enforced by a scheduled daily job registered at install, not by a promise.

Each record holds Salesforce record ids, the object's API name, a failure category, the service's own error text, a latitude and longitude, a geocode accuracy value, a territory model id and a correlation id. No names, no addresses, and no account fields beyond coordinates the record already holds.

Data held by the geospatial service — the retention policy, and the two things it does not do. This is the section a procurement team will stop on, so it is written without softening:

• A 30-day deletion window is built, and it is not yet in effect. Every table the service creates is recorded, and a marked table is dropped by a scheduled sweep 30 days after it is marked. The 30 days are a recovery window, not a processing delay: the selection that produced a territory is not stored, so once the geometry is gone it cannot be rebuilt, and an accidental deletion would otherwise be unrecoverable. The sweep starts with the service process, and the build running today has not been restarted with it — so a deletion is currently carried out by us by hand, as described in the next point, and not by the sweep. We will change this sentence on the day that changes rather than let the stronger reading stand.
• 🔴 There is no self-service delete control in the product, and that is a deliberate decision rather than missing work. Our geospatial service authorises per organisation, not per user, so a delete button in the application would be usable by any user of your org with the same effect as your administrator. A deletion request sent to the security contact in §13 is carried out by us, against a written procedure, and we confirm the date it completes. We will add self-service deletion when per-user enforcement reaches that service, and not before.
• 🔴 Uninstalling the managed package deletes none of the geospatial data, and we will not claim an uninstall-time deletion we cannot make run reliably. Uninstalling removes the package and the assignment-failure log it ships. It also does not delete your Salesforce territory records — those are platform data in your org and remain yours; Salesforce does not permit an application to delete a territory record at all, and your administrator removes them from Setup whenever you choose.
• Deletion applies to our live database. Database backups taken before a deletion still contain the data and expire on their own retention schedule; we do not selectively edit backups.

Application logs cannot be deleted per subscriber — they are shared log groups. They expire at 30 days.

Audit logging and alerting. We do not currently operate infrastructure audit logging, security monitoring or alerting on the hosting account. Enabling audit logging is decided and planned. We do not claim monitoring we do not have.

---

8. Vulnerability management

What actually runs, stated as what runs rather than what we intend:

Territory Mapper's own security review is internal, evidence-based and adversarial — every claim on this page traces to a measurement, and the gaps on it were found by that review rather than reported to us. That is what we have instead of a certification, and we would rather say so than dress it up.

---

9. Incident response

We do not yet operate a formal incident-response program. What we commit to today:

• A named contact. Reports go to the address in §13 and are read by a person, not a queue.
• Acknowledgement within two business days of a report reaching that address.
• Notification without undue delay, and within 72 hours of confirmation, to any subscriber whose data we confirm was affected by a security incident — including what we know, what we do not yet know, and what we are doing.
• We will not wait for certainty to tell you something is wrong.

We will not claim a documented incident-response plan, an on-call rotation, or a tested runbook, because we do not have them. Establishing them is planned.

---

10. Subprocessors

Third parties that process data on our behalf, or that receive end-user requests directly. This list was derived by reading our infrastructure and our application source, not by listing what we expected to find.

Two things worth being precise about.

Basemap tiles are requested by the end user's browser, directly from the provider. They do not pass through MapKraken infrastructure. The provider therefore sees the viewer's IP address and which part of the map they are looking at. It receives no Salesforce data, no territory data and no identity. Four of the five are user-selectable from the map's layer control; OpenStreetMap is the default. If your security policy restricts which external tile providers may be contacted from within Salesforce, tell us — the set is a configuration decision and it is not yet fixed.

The census boundary tiles the product draws territories from are served from our own infrastructure, not a third party. They are public U.S. Census Bureau reference data and carry no subscriber content.

Salesforce is not listed as a subprocessor. Your Salesforce org is your platform, under your contract with Salesforce; Territory Mapper is a tenant of it, not a processor for it.

Nothing else. We verified against the application source that there is no analytics service, no error-tracking or crash-reporting service, no font CDN, no session-recording tool and no email service in the shipped product. There is no telemetry to disclose because there is none.

What this table does not yet state. The contracting jurisdiction for each subprocessor, and our position on international data transfer, are not published here. Every subprocessor above is named, and what each receives is stated; the legal framing around them is not settled and we would rather leave it blank than draft it ourselves. If either matters to your assessment, ask — the underlying facts are the ones in this table and they will not change when the framing arrives.

---

11. Compliance

Every answer in this section is no or not yet. That is the whole section, and it is why it is short.

SOC 2 — no. MapKraken Labs does not hold a SOC 2 report, and no audit is under way. We are a small organisation and a Type II report is a meaningful undertaking; it is on the roadmap, without a date we would ask you to rely on. What we offer instead, today: this page, a completed security questionnaire, and direct access to the people who built the system. If a SOC 2 report is a hard procurement requirement, it is not something we can satisfy now, and we would rather you know that in the first conversation than the fourth.

Data Processing Agreement — not yet. A DPA template is not yet available. One will be provided before any production subscriber agreement is signed. If your procurement process requires a specific DPA form, we will work from yours.

Accessibility (VPAT / ACR) — no. MapKraken has not produced a VPAT or an Accessibility Conformance Report, and we do not claim WCAG conformance. The product has low-cost hedges rather than a conformance programme. We treat accessibility work as a scoped engagement rather than a baseline claim, and we will scope it honestly against your requirement — including the parts of a map interface where conformance is genuinely hard, which we would rather discuss than paper over.

Data residency. All MapKraken-operated infrastructure runs in Amazon Web Services us-east-1, in the United States. There is no non-U.S. deployment option today.

---

12. What we do not claim yet

Collected in one place, so you do not have to assemble it from the sections above. Each of these is either absent or incomplete today. None of them is written in a way that lets a reader mistake a plan for a control.

Why this section exists. A trust page that lists only controls is a marketing page. Every item above was found by our own review, is tracked with an owner, and is written here in the same words we use internally. If any of them is a blocker for you, say so — we would rather lose the evaluation early than pass it on a misreading.

---

13. Security contact

Report a vulnerability to security@mapkraken.com. It is a monitored mailbox, read by a person, and mail sent to it is authenticated — mapkraken.com publishes SPF, DKIM and DMARC, so a reply from us can be verified as ours and a forgery of us can be rejected as not.

What to include: what you found, where, and the steps to reproduce it. A proof-of-concept helps. If you believe the issue is being actively exploited, say so in the subject line.

What to expect: acknowledgement within two business days, an assessment and a remediation plan, and credit in our disclosure record if you want it. We do not operate a paid bug bounty.

Testing in good faith — we have not published a safe-harbour position yet, and we are not going to imply one. A statement that we will not pursue legal action over good-faith research is a legal commitment, and ours is with counsel rather than written by us. Until it is published here, please treat this section as describing where to send a report, not as a grant of permission to test. Two requests in the meantime, and they are the ones that would be in any such statement anyway: do not access, modify or exfiltrate another subscriber's data or degrade the service for others, and do not test against a subscriber's Salesforce org — it is theirs, not ours. If you want to test and the absent safe harbour is what is stopping you, write to the address above and ask; we would rather have that conversation than not get the report.

Everything else: the same address reaches us.

---

Last updated: 2026-08-22 · Owner: MapKraken Labs LLC

This page changes whenever our security posture changes. It is derived from an internal review document that carries the evidence for every claim on it, and it is re-verified against that document rather than edited independently. A claim that stops being true is removed the same day it stops being true.