NimTrace / Security

Security at NimTrace

NimTrace was designed read-only from day one. Here's exactly how we protect your cloud infrastructure and your data.

Zero write permissions
Per-tenant isolation
Short-lived credentials

Cloud Access

Read-only by design, not by policy

Most tools say they're read-only through code logic. NimTrace enforces it at the IAM level: the role deployed in your account literally cannot write, create, update, or delete anything.

IAM read-only enforcement
The access role you deploy via CloudFormation has no write, create, put, delete, or update actions. Even if our code attempted a write, the IAM policy would deny it at the AWS API level.
ExternalId confusion-deputy protection
Every tenant is assigned a unique UUID ExternalId. This UUID must be present in every STS AssumeRole call. A third party who knows your role ARN cannot assume it without the ExternalId.
Short-lived STS tokens
NimTrace never stores AWS credentials. Every API call uses temporary STS tokens with a 1-hour TTL, issued at query time and never written to disk or logs.
GCP & Azure credential encryption
GCP service account JSON and Azure service principal credentials are stored encrypted in a dedicated secrets vault using managed encryption keys. They are never returned to the browser and are only accessed by the backend at query time.

Access Model

What NimTrace can see, and what it can't

Every request is authenticated, every action is scoped to your tenant alone, and nothing reaches your cloud without going through the read-only role you explicitly deployed. Those are the guarantees that actually matter for assessing risk.

Authenticated at every step
Every request carries a verified session token. Your tenant identity comes from that token alone, never from anything a client could forge or supply directly.
Isolated internal systems
Nothing that touches your data is reachable from the public internet. Only our authenticated web application can reach the systems that talk to your cloud.
Your role, your boundary
Access to your cloud happens strictly through the read-only role you deploy and control. Revoke it at any time and access stops immediately, with nothing else to unwind.
No standing access
Nothing is fetched from your cloud until you actively ask a question. There's no background crawler and no persistent connection sitting open against your account.

Infrastructure

How the NimTrace platform is secured

Security measures applied to NimTrace's own infrastructure.

Layer Control Details
Network Web application firewall Rate limiting (2,000 req/5min/IP) plus managed threat-detection rulesets protect every request before it reaches our systems
Network Private backend services All backend services run in an isolated private network with no public IP addresses. Only our authenticated web application can reach them
Auth Verified session tokens All API endpoints require a valid, cryptographically verified session token. The tenant ID is extracted from the verified token, not from user-supplied headers
Data Tenant isolation Every stored record is scoped to a single tenant by construction. Cross-tenant data access is structurally impossible, not just access-controlled
Data Encryption at rest All stored data (conversation history, tenant records, and static assets) is encrypted at rest using managed encryption keys
Data Encryption in transit TLS 1.2+ is enforced between your browser and NimTrace, and between NimTrace and your cloud provider's APIs. Internal traffic never leaves our private network
Secrets Secrets vault Stripe keys, GCP service account JSON, and Azure service principal credentials are stored in a dedicated encrypted secrets vault, never in environment variables or source code
Compute Isolated containers Our workloads run in fully managed, isolated containers with no shared host kernel exposure and no servers for us to patch

Vulnerability Disclosure

Responsible disclosure policy

We take security seriously. If you discover a vulnerability in NimTrace, we want to know about it so we can fix it quickly.

How to report
Send your findings via our contact form. Please include:
  • A description of the vulnerability
  • Steps to reproduce
  • Potential impact
  • Any proof of concept (if safe to include)
Our commitments
  • We will acknowledge your report within 2 business days
  • We will keep you informed of our progress
  • We will not pursue legal action for good-faith reports
  • We will credit you (if desired) once the issue is fixed

Please do not access or modify data belonging to other tenants, perform denial of service attacks, or use automated scanners without prior discussion.

Questions about security?

We're happy to discuss our security posture with your team. Reach out and we'll respond within one business day.

Contact us