Privacy policy

Last revised 2 October 2026. In effect from 22 September 2026.

This policy explains what MarshalCloud collects, why, who else sees it, how long we keep it, and what you can ask us to do about it. It is written from what the product does today. Where a practice is narrower or broader than people usually assume, or where something is not built yet, we say so.

1. Who we are

DEVINSEC PVT. LTD (“DevInSec”, “we”, “us”), Kathmandu, Nepal, operates MarshalCloud at marshalcloud.com and app.marshalcloud.com. MarshalCloud is a product of DEVINSEC.

• For the account details of the people who sign in, and for visitors who contact us, we decide how the data is used (we are the controller).
• For the data we read from your cloud accounts, repositories, clusters, and tracked computers, we act on your organization’s instructions (we are a processor, and your organization is the controller). The data processing addendum governs that.
• One inbox handles privacy requests, legal notices, and security reports, from anyone and from anywhere: hello@marshalcloud.com. This policy names no separate data protection officer and no representative in the EU or the UK; that inbox is the contact for every privacy matter.

We are a company registered in Nepal, and Nepal’s privacy law (the Individual Privacy Act, 2075 (2018)) applies to our handling of personal data. Where another privacy law, such as the EU GDPR or the UK GDPR, applies to data about people in its territory, the rights it gives are available through the same inbox. This policy is governed by the laws of Nepal.

2. What we collect

2.1 Account data

For each person with a login: email address, name, a password hash (we never store the password itself; it is hashed with PBKDF2-HMAC-SHA256 at 600,000 iterations with a per-user salt), an optional profile picture or picture address, the role they hold in each organization, whether and when they verified their email, when they finished onboarding, and when the account was created. If they turn on two-step sign-in, we also store the authenticator secret (encrypted) and hashes of their one-time recovery codes. For each organization: its name, plan, type, a business category, and optional branding (company name, logo address, colour). We also keep invitations (the invited email, the role, and who sent it) and each person’s cookie and email consent choices (see 2.9).

2.2 Account security log

We record security events for each user: sign-ins and failed sign-in attempts, password and two-step sign-in changes, profile changes, API key use, consent changes, data exports, and changes to who belongs to an organization. Each event stores a short description, the IP address it came from, the browser’s user-agent string and the device type and browser read from it, an approximate location (country, region, and city), and the time. The location comes from a lookup table held on our own servers; no third party is asked. Failed sign-ins are counted from this log to lock out password guessing. Users with the infosec role or above in an organization can see that organization’s activity log.

2.3 Cloud and tool data

When you connect an AWS account, the Service reads:

• Billing and usage records: cost line items with the billing period, service, region, account, resource identifier and name, charge description, usage quantity, cost figures, and the tags you have applied to your resources.
• Resource configuration: the inventory needed to map your architecture and find waste and risk, including instance types, disk sizes and encryption state, database engines and versions, network ranges, private and public IP addresses, and firewall rules.
• Utilization metrics: CPU, memory, and network figures.
• Change records from your CloudTrail event history: what was done, to which resource, when, from which IP address, and the identity that did it, which is often a person.
• Identity and security posture: your IAM user names, the IAM credential report, access key age, and whether each user has MFA; the names (not the values) of secrets in Secrets Manager; the names of log groups (not their contents); and findings from AWS Inspector, GuardDuty, and Security Hub where you use them.

For other connections:

• Google Cloud: you grant our service account access. It queries your billing export tables in BigQuery, reads inventory with viewer access, and reads Recommender and Security Command Center results. We store only the project and table names for the connection.
• Azure, DigitalOcean, and Linode: inventory and cost data from their APIs. Hetzner and Hostinger: inventory. Cloudflare: the DNS zone you connect, for build features. Each uses the token or service principal you give us.
• Kubernetes, if you install our cluster agent: node, namespace, pod, and workload names; CPU and memory requests and usage; each node’s cloud instance ID; node readiness; and the names of pods waiting to be scheduled with the scheduler’s reason. No pod logs, no secrets, no container filesystems.
• Datadog, Sentry, and New Relic: events, issues, and signals exposed to the token you give us.
• GitHub (token connection): Dependabot, code scanning, and secret scanning alerts, including the type of an exposed secret and the file path where it was found.

What we do not read. The Service does not read the contents of your databases, object storage, application logs, or backups, with these exceptions, each of which you turn on:

• AWS cost export files, which AWS itself writes into a bucket in your account, read only under the export prefix; and your Google Cloud billing export tables.
• Workload scanning: a scanner we set up in your account makes temporary copies of server disks and reads the list of installed software packages. The package inventory (names, versions, and the server’s name) is sent to us.
• Delivery: through our GitHub App we read your repository’s file list and selected files (such as Dockerfiles, workflow files, task definitions, and lockfiles), store a summary of what we found, and for a build copy an archive of your repository at a commit into a storage bucket in your own cloud account.

2.4 Credentials

The standard AWS connection is a cross-account role plus a secret external ID, so we hold no long-lived AWS keys for it. Where a key, token, or secret is used instead (an AWS access key, an AWS IAM Identity Center token, an Azure service principal secret, a provider API token, a Datadog, Sentry, New Relic, or GitHub token, or your own AI provider key), the application encrypts it before storing it, and it is never shown in the product, never returned by our API, and removed from our logs. Kubernetes agent tokens, device reporter tokens, and MarshalCloud API keys are stored only as hashes.

Webhook addresses and paging phone numbers are different: they are stored in our database, which is encrypted at rest, but they are not additionally encrypted by the application. They are shown masked (a webhook by its host, a phone number by its last four digits).

2.5 Monitoring results

For each check of a website, endpoint, TCP port, DNS name, or heartbeat we store: the organization, the monitor, the time, whether it succeeded, the HTTP status code, the response time, and error text shortened to 200 characters. For monitored addresses we also check certificate and domain expiry once a day; the domain lookup sends the domain name to public domain registry (RDAP) services.

2.6 Device telemetry

If you choose to install the MarshalCloud device reporter on a computer, that computer sends a snapshot every ten minutes. The snapshot contains exactly these fields, and nothing else:

• operating system family and version string
• hostname
• how long the computer has been powered on
• total disk size, disk used, and percentage used
• total memory and processor count
• the number of pending operating system updates
• whether the built-in firewall is on
• whether disk encryption is on

The reporter does not collect usernames or who is signed in, installed applications, running processes, browsing history, files or file names, screenshots, keystrokes, location, serial numbers, or MAC addresses, and we do not store the computer’s IP address. It only reads, and it never changes anything on the computer. It is a plain Python file you download and can read before you run it.

If you install the reporter on computers used by your staff, this is employee monitoring, and you are responsible for it. MarshalCloud is your processor for this data. You must tell the people who use those computers what is collected, and you must have a lawful basis for doing so. Depending on where they are, that can also require a consultation with employee representatives, a notice, or an impact assessment. We do not do that for you and cannot check that you have.

2.7 Product records

• Actions you propose and approve: who proposed, who approved (including a Slack user ID for approvals from Slack), each step, and the rollback record.
• Alerts and their delivery results, incidents, status updates, postmortems, on-call rotations (members’ names and emails), and paging phone numbers with the email of the person each one reaches.
• Recommendations, security findings, budgets, reports, and share links.
• Compliance questionnaires (questions, answers, citations, reviewer emails) and policy documents you add as text.
• Build records: environments and stacks, plans, run logs, outputs, approvals, restore points, and, for shell access, who asked, why, who approved, which server, and when the session started and ended. The session’s own recording stays in your cloud account; we keep only a pointer to it.
• AI conversations and messages, the record of each AI run and what it read, token usage, and any AI instructions or skills your admins write.
• A log of each email we send: recipient address, subject, the data used to fill the template, and the delivery result. Addresses that bounce or complain are kept on a do-not-send list.

2.8 Visitors who are not signed in

• Contact form: your name, email, company, message, the time you ticked consent, and a salted hash of your IP address (not the address itself). We email you an acknowledgement and forward the submission to our team.
• Free bill scan: the file you upload is read in memory and never stored. We keep only the summary and findings, under a private link, for 7 days unless you sign up and claim them. No email or name is asked for.
• Your IP address is used in memory to apply rate limits, and is not stored for that purpose.

2.9 Cookies, browser storage, and consent

The MarshalCloud application does not set cookies. It uses your browser’s local storage and session storage for these purposes:

• your sign-in token (local storage, until you sign out; the token itself stops working after 24 hours);
• which organization and connection you last selected, your light or dark theme, report preferences, diagram layout, build and onboarding progress (local storage);
• a pending invitation or an unclaimed bill scan while you sign up, and the scope of an analysis in progress (session storage, cleared when the tab closes).

No analytics or advertising tracker is loaded by our code on the app or on the marketing site, and our code sets no cookie. The marketing site is served by Cloudflare, and our site’s security settings allow Cloudflare’s Web Analytics script to run. Whether that script is turned on, and whether Cloudflare sets a cookie of its own on the site (for example for a bot check), is controlled in Cloudflare’s settings rather than in our code, and is governed by Cloudflare’s own terms and privacy policy. We make no promise about it beyond that.

After you sign in, the app asks for your choices on marketing emails and emails about your account. We record each choice with its category, the policy version, where you made it, your IP address, and the time. The app runs no usage analytics, so it no longer asks about them; an answer you gave before stays on record. If we add usage analytics, the choice comes back and we ask before they run. One limit, stated plainly: emails are controlled by your email preferences and unsubscribe links, not yet by the consent choice. Signed-out visitors to the marketing site are not shown a consent choice.

3. Why we use it

• To provide the Service you asked for: spend, monitoring, security findings, recommendations, builds and deploys, and carrying out changes you approve.
• To send alerts, reports, and service messages through the channels you configure.
• To keep accounts and infrastructure secure, detect abuse, and enforce plan and rate limits.
• To bill you and keep financial records.
• To answer you when you write to us.

We do not sell personal data, we do not share it for advertising, and we do not train AI models on your data. What an AI provider does with data it receives is governed by that provider’s terms; see section 5.

4. Legal bases

Where the law that applies to you asks us to name a legal basis, we rely on these: contract, for account data and delivering the Service; legitimate interests, for security logging and abuse prevention; legal obligation, for tax and accounting records; and consent, for optional emails. For cloud, repository, and device data we are the processor, so your organization chooses and documents its own basis. That includes monitoring its staff’s computers with the device reporter: we do not advise on whether that is lawful where you are, and we cannot check that you have told the people affected.

5. Artificial intelligence

MarshalCloud uses AI models to answer questions about your data, summarize incidents, draft postmortems and questionnaire answers, review infrastructure plans, write weekly briefings, and search your own findings. By default these requests go to MarshalCloud’s own accounts with Anthropic and OpenAI. The interactive assistant uses Anthropic; if Anthropic is unavailable the same request can be sent to OpenAI instead. Summaries, drafts, plan reviews, weekly briefings, and search indexing use OpenAI.

An admin can instead connect your organization’s own key for Anthropic, OpenAI, or OpenRouter, or an OpenAI-compatible endpoint of your choice. Requests then go to that provider under your own agreement with it. OpenRouter passes requests on to the model provider it routes them to.

What can be sent, depending on the feature:

• your question and the earlier turns of that conversation;
• cost totals and recommendations with dollar estimates;
• resource identifiers, names, types, regions, and states;
• monitor names, states, response times, expiry dates, and the latest error text;
• incidents, status updates, postmortems, and on-call rotations;
• security findings, compliance control states, and change records including who made a change;
• infrastructure plans and their changes, stack settings (a setting marked sensitive is sent only as “set”), and drift between what was built and what exists;
• policy documents and past answers, when drafting a questionnaire;
• instructions and skills your admins wrote, advice left by an operator during an incident, and earlier AI answers for your organization from the last 30 days.

Before a request is sent, the Service replaces email addresses, phone numbers, IP addresses, AWS resource names (ARNs), 12-digit account IDs, and AWS access key IDs with stable pseudonyms, and shortens and cleans the data the assistant’s tools return. This is pattern-based, so a person’s name written in free text (for example in an incident note) is not replaced. Advice an operator leaves during an assistant run goes through the same replacement.

We have found no path that sends your cloud credentials or device telemetry to an AI provider. The AI can propose an action, and leave drafts described in section 3.6 of the terms, but cannot approve or carry out any change.

The Service does not set any zero-data-retention option on these requests. What Anthropic and OpenAI keep from a request, for how long, and what they do with it is governed by each provider’s own terms for API customers, not by anything in our code. We make no promise about their retention beyond those terms.

6. Who else sees your data

• Subprocessors. The current list, what each is for, and what it receives, is at marshalcloud.com/legal/subprocessors.
• Errors in our own software. When the service itself fails, a report goes to Sentry with email addresses, keys, tokens and account IDs removed first, and never a request body, cookie, sign-in header or IP address. The subprocessors page lists exactly what it receives.
• Our staff. Staff roles are separate from customer roles. A superadmin has owner-level access to every organization and can suspend, archive, or delete an organization, and set a temporary password for a user. A platform reliability role can read every organization but change nothing. A support role can see a directory of organizations, users (names and emails), members, and invitations. A security oversight role sees compliance and staff activity views, not organization data. When staff open your organization from our console, that is written to your organization’s activity log, at most once an hour per person; reading through the API directly is not logged per read. Staff administrative actions are recorded in our own log.
• Where you send it. If you configure email, Slack, a webhook, SMS, or voice paging, alert text goes there. Uptime alerts can include the monitored address and error text; device alerts include the computer’s name and its issue.
• Your repositories. Pull requests we open are visible to everyone with access to that repository.
• An agency you link. Every admin and owner of the agency organization can act in your organization up to the ceiling role set on the link. Only the agency can remove the link in the product today; we remove it on request.
• Legal. We may disclose data where the law requires it, and we will tell you unless we are prohibited from doing so.
• Corporate change. If we are acquired or merged, data may transfer with the business, subject to this policy.

7. How long we keep it

8. Your rights and what you can do yourself

Under whichever privacy law applies to you, you can ask us to see, correct, delete, or export the personal data we hold about you, or to stop a particular use of it. Write to hello@marshalcloud.com. We will respond within 30 days, and we may first ask you to confirm who you are. If you are an employee whose work computer is tracked, contact your employer first: they decide what is collected, and we will refer your request to them.

• See and correct. You can edit your name and picture on your account page.
• Download your personal data. Your account page gives you a file with your profile, organizations and roles, consent choices, and account activity including IP addresses.
• Erase your account. Your account page erases your name, email, picture, password, and sessions, removes pending invitations to your address, and removes your email from other people’s activity records. It is refused while you are the only owner of an organization. Your activity history, consent decisions, and organization memberships stay, tied to an anonymous ID, and invoices stay where the law requires them. Your encrypted authenticator secret and recovery code hashes are not yet removed by this step; ask us and we will remove them.
• Export organization data. Partial. The product exports cost breakdowns, the asset inventory, compliance evidence, questionnaires, and the organization activity log as CSV, and can share reports by link. There is no single export of everything an organization holds; we produce one by hand on request.
• Delete an organization. Our staff do this on request, as described in section 10 of the terms. It does not remove the users’ own accounts, which each person can erase.
• End our access. Delete the roles you installed in your cloud account, uninstall the cluster agent or our GitHub App, or remove a computer. Access stops at that moment.

9. How we protect it

• Connections to the application use HTTPS (TLS 1.2 or 1.3).
• Our database, cache, analytics store disk, and the file storage that holds customer data are encrypted at rest with AWS KMS keys that rotate automatically.
• The credentials and tokens you supply (cloud connections, integration keys, authenticator secrets, your own AI key) are also encrypted by the application with a key held in AWS Systems Manager Parameter Store, encrypted with a KMS key. It is an application key, not per-record envelope encryption. Our own service secrets (payment, SMS and GitHub App keys) are deployment configuration in that same store, not database rows.
• Every request is checked against the caller’s membership of the organization, and every record fetched by ID is checked against that organization.
• Two-step sign-in with an authenticator app is available and optional. Sign-in tokens expire after 24 hours, and you can sign out everywhere at once.
• Outbound webhooks must use HTTPS to a public address, and monitors refuse private and internal addresses.
• Infrastructure changes come only from a fixed catalog or a reviewed plan, and wait for a person’s approval.
• Rate limits apply to every address, with a stricter limit on sign-in, and AI usage is capped per organization.
• Open items, stated rather than hidden: sign-in tokens are held in browser local storage rather than a hardened cookie; an email address must be verified before an invitation can be accepted, but not before an account can otherwise be used; two-step sign-in cannot be required by an organization; and we hold no SOC 2 or ISO 27001 report.

10. Where your data is

MarshalCloud runs in Amazon Web Services’ Asia Pacific (Mumbai) region, in India. Our database, cache, analytics store, and file storage are there. Copies of our own software images, which contain no customer data, are also kept in AWS’s US West (Oregon) region. When you connect an AWS account with one click, the setup stack in your account sends a message to a notification topic we run in AWS’s US East (N. Virginia) region whenever the stack is created, updated, or deleted; AWS requires that topic to sit in the same region as the stack. The message carries your AWS account ID, the read role’s ARN, the external ID for that connection, the name of the cost export bucket, the stack’s own identifiers, and a one-time address for our reply. It carries no password or access key. The topic hands it on to a queue in Mumbai and does not keep it once delivered; the topic is not encrypted at rest with a key of ours. Our company is in Nepal. We do not restrict the countries from which our staff access customer data, so staff access can happen from outside India and Nepal. Subprocessors process data in the countries their own terms set, as the subprocessors page explains. If the law where you are requires a particular safeguard before personal data is sent to India, Nepal, or a subprocessor’s country, the data processing addendum is the only transfer document we offer; it includes no standard contractual clauses, and we promise no other safeguard. There is no data residency option: we cannot keep your data in a region you choose.

11. Children

MarshalCloud is a business tool, not directed at children, and we do not knowingly collect personal data from anyone under 18. If you believe a child has given us data, write to hello@marshalcloud.com and we will delete it.

12. Changes to this policy

If we change this policy in a way that materially affects you, we will email your organization’s owners at least 30 days before it takes effect. The date at the top shows when it was last revised.