Trust: access and data handling

How Mission FinOps, an independent AWS consulting practice, accesses, processes, and protects customer data. Investigations favor local-first, read-only access and customer-controlled evidence. Implementation is scoped separately, including access, responsibilities, and risk boundaries.

Investigation controls

default-controls ACTIVE

AWS access: Read-level. Published IAM policy.
execution: Customer-controlled execution supported and preferred.
billing-data upload: Not required.
SaaS ingestion: None.
telemetry: None.
write actions: None.
source visibility: Open-source tooling. Inspectable before execution.
credentials stored: No. Customer-managed credentials only.

telemetry: 0 mandatory data upload: 0

How an investigation works

I do not require customers to forward their AWS billing estate into a Mission FinOps SaaS platform. Investigation tooling can execute within the customer's controlled environment using approved read-level permissions.

  CUSTOMER CONTROL BOUNDARY  ──────────────────────────────────────────────  AWS Billing / CUR / CE / Resource Metadata                    │                    ▼          Kulshan / Read-level queries                    │                    ▼           Evidence / Findings  ──────────────────────────────────────────────                    │                    │ selected findings /                    │ customer-approved output                    ▼            Mission FinOps report  No mandatory raw billing-data upload.

Customers choose the operating model appropriate to their security requirements:

customer-operated: Customer runs Kulshan and provides selected outputs. Mission FinOps never touches the AWS environment.
supervised investigation: Mission FinOps works in a customer-provided workstation, VDI, or account with approved read-level access.
export-based: Customer provides specific billing exports or reports. No AWS access granted to Mission FinOps.

Investigation access

I do not require AWS write permissions for a standard investigation. The published IAM policy contains read-style actions only.

no IAM administration: No IAM policy changes. No role creation.
no credential persistence: Temporary, customer-managed credentials preferred.
customer-restrictable: Customers may further restrict the published policy to the agreed investigation scope.

The full IAM policy is published, SHA256-attested, and downloadable.

iam-policy source-code

Data handling

Data I may process

billing: AWS billing and cost records, CUR line items, Cost Explorer outputs.
resource: Resource identifiers, account metadata, tags, usage information.
context: Architecture context supplied by the customer during the engagement.

Data I do not require for an investigation

credentials: Customer passwords or long-lived access keys.
production data: Database contents, application payloads, end-user PII.
source code: Customer source-code repositories.
write access: Write access to production resources.

Where data goes

The default architecture does not require customer AWS billing data to be copied into Mission FinOps infrastructure. Customer data does not cross a new SaaS boundary. Your billing data stays under your control.

Retention

Customer evidence remains in the customer environment whenever practical. Any customer-supplied working files retained by Mission FinOps are limited to the engagement scope and deleted according to the agreed retention period.

Specific retention terms are documented in the engagement scope confirmation before work begins.

AI and model use

Numbers come from deterministic code, not a model. If AI helps with an investigation, it runs where you choose, your data is not used to train anything, and I review every finding before you see it.

Software supply chain

You do not have to trust a black-box agent with unrestricted cloud access. The core investigation tooling and permissions are inspectable before execution.

repository: github.com/MissionFinOps/kulshan
license: Apache 2.0
IAM policy: Published, SHA256-attested, downloadable JSON.
telemetry: None. No phone-home. No usage tracking.
design: Read-only by construction. No write path exists.

github iam-policy

Separately scoped implementation

If the work requires changes to your AWS environment, I agree the implementation scope, access, responsibilities, and risk boundaries with you before making changes. Investigation permissions do not authorize implementation. Kulshan and its published IAM policy remain read-only.

I can co-deliver with your existing engineering team or consultancy. Everyone involved is named, responsibilities are explicit, and access requires your approval.

Human access

personnel: Named personnel only. Currently the founder.
privilege: Least privilege. Customer-approved access scope.
identity: Customer-controlled identity where possible. MFA required.
duration: Access removed at engagement conclusion.
subcontractors: No access extended to any third party without explicit customer approval.

Enterprise documents

Available during vendor review:

Available now

IAM policy: Published at /policy/ with SHA256 hash and downloadable JSON.
source code: Open-source at github.com/MissionFinOps/kulshan.
data-flow diagram: Shown above. Available as a standalone document on request.
security architecture: Engagement-specific architecture and data-flow documentation available during review.

Available during contracting

NDA: Mutual NDA available.
data handling statement: Engagement-specific data handling and retention terms.
security questionnaires: Completed on request.

Security contact

Security or vulnerability disclosure: hello@missionfinops.com

Enterprise review or procurement questions: hello@missionfinops.com

Controls described here are the default Mission FinOps operating model. Engagement-specific requirements are documented and agreed before access to customer data or systems.

Last updated: October 2026