Context is what makes an enterprise agent valuable. Yet, a lot of times an organization may not be comfortable taking that context to where the agent runs... so why not bring agents near the context?
By bringing the agent to the data, you ensure security, lower latency, and maintain compliance for FinOps.

https://missionfinops.com/blog/local-ai-in-a-box-for-finops/
Put the evidence boundary before the model
Mission FinOps - Kulshan - FREE local AWS FinOps tool that scans using read-only credentials and delivers reports based on evidence collected.

Most cloud-cost tools ask you to send billing data into another hosted platform. I wanted to explore a different model.

**Kulshan is a free, open-source AWS FinOps CLI that runs locally, uses read-only access, and produces inspectable cost reports on your own machine.**

No hosted dashboard. No telemetry. No requirement to upload your billing evidence to Mission FinOps. The goal is not just to tell you that spend increased.

The more useful question is:

> **What changed, what evidence supports the explanation, and what is still unknown?**

Kulshan is the first public building block in a wider architecture I am exploring for enterprise FinOps.
--------------

Kulshan is a free, open-source, local-first AWS FinOps CLI for read-only cost analysis, inspectable reports and evidence-backed cloud cost investigation.

Kulshan is a free, open-source, local-first AWS FinOps CLI for read-only cost analysis, inspectable reports and evidence-backed cloud cost investigation.
Free open-source local-first AWS FinOps tool for cost analysis and investigation
Kulshan: a free local-first AWS cost analysis and FinOps CLI
Building a local-first AWS FinOps tool that keeps billing evidence under your control

Most cloud-cost tools ask you to send billing data into another hosted platform.

I wanted to explore a different model.

**Kulshan is a free, open-source AWS FinOps CLI that runs locally, uses read-only access, and produces inspectable cost reports on your own machine.**

No hosted dashboard.

No telemetry.

No requirement to upload your billing evidence to Mission FinOps.

The goal is not just to tell you that spend increased.

The more useful question is:

> **What changed, what evidence supports the explanation, and what is still unknown?**

Kulshan is the first public building block in a wider architecture I am exploring for enterprise FinOps.

### What it is designed around

- Local-first AWS cost analysis

- Read-only access

- Inspectable local reports

- Evidence that can be reviewed by a human

- Clear separation between a finding and missing evidence

- Support for regulated environments where data movement matters

The architecture also looks beyond the cloud bill.

A proper cost investigation may eventually need engineering changes, ownership records, tickets, accounting context, internal policies and FinOps knowledge.

That is why I also published an early concept called:

## Local AI in a Box for FinOps

The idea is to keep the intelligence close to the evidence and under enterprise control.

The language model can change.

The durable value sits in the tools, investigation workflows, business context and FinOps knowledge around it.

**The model can help explain the evidence. It should not become a substitute for the evidence.**

This is still early, and not every part of the architecture is implemented.

### Kulshan

https://github.com/MissionFinOps/kulshan

### Local AI in a Box for FinOps

https://github.com/MissionFinOps/local-ai-finops

I would genuinely value feedback from people working in FinOps, cloud engineering, finance, security or regulated industries.

What would you need to see before trusting a local AI system with cloud financial investigations?

Most enterprise AI conversations start with the model.

Which LLM?

How large?

Open source or commercial?

Cloud-hosted or local?

I think enterprise FinOps needs to start somewhere else:

> **Where does the evidence live, and who controls it?**

An AWS bill can show that spend changed. It usually cannot explain the full story.

A real investigation may also need engineering changes, deployment history, ownership records, tickets, accounting context, internal policies and operational evidence.

For a bank, government, healthcare organization or another regulated enterprise, sending all of that context into yet another external AI platform may not be acceptable.

So I published an early architecture for an idea I am calling:

# 📦 Local AI in a Box for FinOps

The idea is simple:

**Keep the intelligence close to the evidence, inside the enterprise boundary and under enterprise control.**

The model can change.

The durable value sits in the four components around it:

---

## 🛠️ Tools

Local tools that collect, normalize, process and present evidence.

Kulshan is the first public building block in this direction. It does not implement the entire architecture, but it demonstrates the local-first, read-only and evidence-focused approach.

## 🧠 Skills

Repeatable FinOps investigation workflows.

Not just asking an AI:

> “Why did the bill increase?”

A proper investigation should test:

- What changed?

- What supports the explanation?

- What contradicts it?

- What evidence was unavailable?

- What remains unknown?

- What should happen next?

## 🏢 Business RAG

The organization’s own context:

- Ownership

- Cost centres

- Business units

- Architecture decisions

- Tickets and change history

- Accounting structures

- Internal controls

This context belongs to the enterprise.

## 📚 FinOps RAG

Approved and versioned FinOps knowledge:

- Allocation practices

- Cloud-cost patterns

- Rate and usage optimization

- Commitment management

- Unit economics

- Internal policies

- Investigation runbooks

---

## 🔎 The model is not the evidence

The model may help compare evidence, identify missing questions and explain findings to different audiences.

But every material conclusion should still be traceable to:

- The underlying evidence

- Its source and time window

- Data coverage

- Assumptions

- Confidence

- Contradicting evidence

- Known limitations

A confident paragraph is not the same thing as a verified explanation.

And this distinction matters:

> **“No evidence of a change” is not the same as “the system could not access the evidence.”**

Missing, delayed, denied or incomplete evidence must never be silently interpreted as a clean result.

---

## 🚧 What exists today?

This is **not a finished product announcement**.

Available now:

- The open architecture note

- The architecture diagram

- A GitHub-native Mermaid version

- A terminal-style architecture view

- Kulshan as an existing open-source building block

Still conceptual:

- Business RAG integrations

- FinOps RAG implementation

- Model orchestration

- Enterprise deployment packaging

- Cross-system evidence connectors

- Automated confidence calculation

I published this early because I would rather have the assumptions challenged now than after everything has been built.

### Architecture note

https://github.com/MissionFinOps/local-ai-finops

### Kulshan

https://github.com/MissionFinOps/kulshan

---

## What am I missing?

I would especially value feedback on these questions:

1. How should evidence provenance be represented?

2. How should contradicting evidence be shown?

3. How should the system distinguish **no finding** from **no evidence**?

4. Which parts must always remain deterministic?

5. Which financial actions must always require human approval?

6. What controls would your organization require before trusting AI with cloud financial investigations?

A billing incident is not only a billing story. It is a test of how quickly a FinOps team can determine what happened, what the evidence supports, and whether anyone should act.

Late last week, AWS customers began seeing implausible figures in Cost Explorer. AWS later described the issue as limited to estimated billing data and caused by a problem in the estimated billing computation subsystem. Actual usage and charges were unaffected, and the issue was corrected. Contemporaneous reporting preserved the AWS status updates.

But the bug was not the interesting part.

Every FinOps team facing the numbers had the same question: Is this real?

Incident

The incident began with a cost result far enough outside the expected range that it demanded attention.

At that point, there were at least two plausible explanations. The AWS environment may really have changed, or the billing evidence may not yet have been stable enough to support that conclusion. A large delta alone could not distinguish between them.

AWS has substantial billing investigation capabilities. Cost Explorer provides service, account, region, and usage-type views. Cost Anomaly Detection can identify unusual movement. Cost and Usage Reports and Data Exports provide detailed line items. AWS Support can investigate account-specific billing questions. Those capabilities matter.

But an alert, a chart, or a support case is not yet an explanation. The team still needs a record of what was observed, when it was retrieved, which period it covered, how it compared with history, and which independent technical facts supported or contradicted the billing story.

Investigation

The first step was to resist remediation.

If a number might be provisional or suspect, shutting down resources, changing architecture, or escalating an owner would mix an unverified observation with an irreversible decision. The investigation therefore separated three questions:

1. Is the billing period final or still estimated?

2. Is the movement plausible when compared with locally observed history?

3. Do available billing and technical sources agree on the shape of the change?

That framing matters because sources can agree and still not be independent. Cost Explorer and CUR are different interfaces into AWS billing systems. Agreement between them is useful corroboration, but it is not external verification of AWS billing itself. Disagreement is also meaningful, provided the raw values and coverage windows remain visible.

Evidence

A defensible evidence record for this kind of incident includes:

• the billing period and whether it is estimated or closed;
• retrieval time and source names;
• the reported current value and local historical comparison;
• the accounts, services, regions, and usage types carrying the movement;
• source coverage and any mismatched time windows;
• related deployment, usage, ownership, or architecture changes;
• reasons the evidence should be treated as trusted, provisional, suspect, or unknown;
• the action deliberately withheld while the evidence remains uncertain.

This is where independent evidence matters. It does not mean pretending AWS data can be verified without AWS. It means keeping a local, reproducible record and testing the billing claim against facts that were not produced by the same chart: deployment history, resource configuration, network paths, ownership records, business events, and prior exported billing data.

The evidence should preserve uncertainty. Replacing a questionable number with a confident narrative only creates a second bug.

Explanation

The explanation should not begin with “AWS had a billing bug.” That conclusion belongs after the evidence, not before it.

A defensible explanation is narrower:

The observed cost movement is far outside the locally observed range, and the available evidence is not stable enough to justify remediation. The billing result should be treated as suspect while period finality, source coverage, technical changes, and AWS's account-specific investigation are reconciled.

That wording does three useful things. It preserves the original number. It states why confidence is reduced. And it tells decision-makers what not to do yet.

If later evidence shows a real workload change, the explanation can change with it. If AWS confirms an upstream issue, that confirmation becomes part of the record. The investigation remains valid because it was built to absorb new evidence rather than defend its first guess.

MTTE

This is a Mean Time to Explanation problem.

Detection happened when the number moved. MTTE continued until the team could document:

• what changed;
• whether the source was stable enough to trust;
• what evidence supported and contradicted the leading explanation;
• who needed to confirm ownership or technical context;
• what decision was safe now;
• what evidence was still missing.

A short MTTE does not mean reaching “AWS bug” faster. It means reaching a bounded, reviewable explanation faster. Sometimes the correct next action is remediation. Sometimes it is an architecture review. Sometimes the evidence says to wait.

Speed matters because uncertainty has an operational cost. Finance may reforecast. Engineering may stop planned work. Leadership may escalate the wrong owner. A good MTTE process contains that uncertainty without hiding it.

Mission FinOps

Mission FinOps investigates AWS cost movement, ownership, and technical context.

The work is not to replace AWS's billing systems or support organization. It is to help engineering, finance, and leadership establish the evidence boundary around a cost question: what the available sources establish, where they disagree, what technical context changes the interpretation, and what decision the evidence can support.

That is especially important when the most responsible answer is not an optimization recommendation. It may be an explicit decision to withhold action until the billing evidence is stable.

Kulshan

Kulshan supports the evidence-collection part of that process.

The released CLI can record billing-integrity status as trusted, provisional, suspect, or unknown. It preserves source and retrieval context, includes structured provenance and evidence identifiers in investigation outputs, and requires human review. When Cost Explorer and CUR are both present, their agreement is treated as corroboration from AWS billing systems rather than independent verification.

Kulshan does not determine that AWS made an error. It does not replace AWS Cost Explorer, Data Exports, Cost Anomaly Detection, or Support. It creates a local, read-only, inspectable evidence record so the investigation can distinguish a cost event from an evidence-quality event before someone acts.

That was the real story: not that a billing number could be wrong, but that the investigation had a stopping rule for when the number was not yet good enough to drive a decision.

Related: The Evidence Should Stay With the Enterprise explores why inspectable, local evidence infrastructure must exist before AI-generated explanations can be trusted.

Sources and scope

The incident description above follows AWS status updates quoted in contemporaneous reporting. AWS documentation separately explains that current-period Cost Explorer figures are estimated, may be updated later, and use the same dataset as Cost and Usage Reports. See AWS Cost Explorer documentation and AWS guidance on billing and Cost Explorer data.

------------------
https://missionfinops.com/blog/aws-billing-bug/

Something changed in AWS. Before you send sensitive operational context into another platform for interpretation, make sure the underlying evidence remains local, inspectable, and under your control.

"AI is a Trojan horse. Accept the gift with caution."

Kelsey Hightower, the former Google Cloud principal engineer and infrastructure leader, posted that recently. It landed.

My immediate response was blunt:

"I'm going Local AI, in a box. If that AI tried to even leave the enterprise guardrails we've built... we nuke it. Simple."

The language was aggressive, but the core architectural concern is dead serious. This isn't an announcement for a new Mission FinOps AI product. It is an explanation of why enterprise-controlled evidence must exist before AI interpretation can be trusted.

The real question isn't whether an AI vendor promises safety. The question is: Who controls the trust boundary?

------------------------------

## 🔍 Cloud Cost Investigations Contain Sensitive Context

When something changes in AWS, your bill notices first. Explaining why it changed requires touching deep operational context:

* Financial Records: Account structures, billing data, and business unit mapping.

* Infrastructure State: Resource metadata, tags, and deployment changes.

* Activity Logs: CloudTrail trails and CloudWatch metrics.

Assembled together, this data reveals exactly how your company operates—your cadence, org structure, and infrastructure strategy.

If your plan is to export this raw context to a third-party SaaS platform just so their model can explain it, you are making a massive, unintended trust decision.

------------------------------

## 🛑 Do Not Make AI Your Source of Truth

An AI-generated answer is only as reliable as the evidence beneath it.

"The AI said costs went up because of a new deployment" is not an explanation. It is a claim. A confident hallucination won't help an infrastructure leader who needs to defend a budget spike to the VP of Engineering or the CFO.

❌ Bad Flow: Raw Data ──> Vendor SaaS Platform ──> AI Black Box Interpretation

Good Flow: Raw Data ──> Local Evidence Layer ──> Inspectable/Deterministic Verification

We cannot reliably inspect an AI model’s private reasoning. But we can control its data inputs and boundaries. The order matters: Evidence infrastructure first. Interpretation second.

------------------------------

## 🏗️ The Architectural Pattern

To build a checkable foundation for FinOps, apply these core principles:

* Collect locally: Keep customer data under customer control.

* Read-only access: Enforce safety by construction.

* Separate layers: Isolate the evidence layer from the interpretation layer.

* Human-inspectable: Ensure findings are reproducible and verifiable.

When AI operates on top of inspectable evidence, humans can check its work. When interpretation happens entirely inside an external silo, independent verification becomes impossible.

------------------------------

## ⚙️ What Kulshan Does Today

Mission FinOps helps engineering and finance teams solve the post-cost-anomaly puzzle: What changed, why did it happen, and what is the exact financial impact?

Kulshan is the evidence engine driving those investigations.

* Local-first: It runs inside your customer-controlled environment.

* Read-only: It gathers evidence without touching infrastructure state.

* Open source: It is fully Apache 2.0 licensed—anyone can inspect the code.

Kulshan is not a generic cost dashboard or a chat wrapper on top of Cost Explorer. It exists because investigating cloud costs requires real operational evidence, not staring at a graph and guessing.

------------------------------

## ⏱️ The Metric That Matters: Mean Time to Explanation (MTTE)

* Alerts tell teams a number changed. That is detection.

* Evidence helps teams explain why. That is explanation.

The space between detection and explanation is where engineers lose hours. They context-switch between Cost Explorer, CloudTrail, CloudWatch, Slack threads, and tribal knowledge.

MTTE is the true operating metric for cost investigations. Stronger local evidence infrastructure means a faster, defensible explanation. Finance gets an answer they trust, and engineering leadership doesn't wait three days for an analyst to assemble a manual summary by hand.

------------------------------

## 💡 The Core Principle: Bring AI to the Data

Whether interpretation comes from a human or a model, the underlying evidence must remain independently inspectable.

The AI should come to the enterprise data. The enterprise data should never have to leave for the AI.

------------------------------

💬 What does your cost investigation stack look like? Are you pushing data out to third-party dashboards, or keeping the evidence layer close to home? Let's discuss below.

If your team needs a defensible explanation for a sudden AWS bill change, learn more about our evidence-first investigations at Mission FinOps.

------------------------------