Early access

Kosli Capture is a concept we're shaping with a select group of customers. We'd value your feedback.

Tell us what you think

Concept preview / AWS first

Kosli Capture. Runtime Evidence on Autopilot.

Instead of instrumenting every cluster, function and account one by one, grant Kosli tightly-scoped read-only access and every in-scope workload across your cloud estate appears in Kosli: continuously monitored, and fully under your control. Available first on AWS, with Azure and GCP designs below. No agents to maintain. No infrastructure to deploy. No Kosli credentials in your accounts.

Talk to us about early access Read the security model

Architecture

Your cloud accounts

Read-only

One read-only grant per account, subscription or project. You control the permission scope.

KubernetesContainersFunctionsStorage metadata

native read-only access, granted and revoked by you

Kosli Capture

Discovers resources, filters them by your tags and labels, derives environments, on a schedule we operate and monitor.

environment recording, with built-in monitoring and liveness alerts

Kosli

A live, auditable record of what's actually running, alongside your existing change evidence.

Runtime Evidence is the last mile of software delivery compliance

Proving what should run is half the job. Auditors and regulators ask what is running. Kosli answers that with Runtime Evidence, but until now getting the answer has meant instrumenting every environment individually and keeping it all alive.

01

Setup burdens your platform team

Per-environment reporters mean change tickets, architecture reviews, and an extensive rollout program. Across hundreds of cloud accounts, "roll it out everywhere" becomes a project of its own.

02

More vendor infrastructure to maintain

Today's self-hosted collectors add a stack per account and region: Lambdas, roles, buckets, log groups, plus a vendor credential to store and rotate. Your team patches and upgrades all of it, forever.

03

Silence indistinguishable from health

A monitoring setup that quietly dies is indistinguishable from an estate that simply hasn't changed. A stale environment view still displays, still looks authoritative, and still gets shown to auditors.

The solution

One read-only role per account. We do the rest.

Kosli Capture inverts the model: instead of deploying our monitoring inside your boundary, you grant Kosli tightly-scoped read access and we operate a fully managed capture service on our infrastructure.

Onboard an account in minutes

Deploy one read-only grant, tell us its identifier, the regions and the tags to track, and in-scope resources start appearing in Kosli within minutes.

Tags are the on/off switch

Your teams control what's tracked with the tags they already apply. New cluster, new function, new account: discovered and reported automatically, no per-resource setup.

Fully managed service on Kosli infrastructure

No infrastructure, no monitoring to build, no stored credentials. Your attack surface doesn't grow, and there's nothing for your team to patch.

Monitoring is baked-in from day one

Kosli monitors the entire capture process, so any problems are taken care of without change tickets or compliance gaps.

Monitoring

Let us take care of availability

Because we run the service, we can guarantee its operation via SLA. We can monitor the capture process and ensure uptime and liveness.

Alerts and logs if reporting stops for any reason (revoked role, network change, our bug)

Failures are diagnosed and fixed by us, from our telemetry. No more "please check your Lambda logs."

Completeness can be achieved without engineering a monitoring solution for every environment

Built for your security review

Designed around the IAM boundary you already trust

This is the same cross-account pattern you already use with your cloud security tooling, but with a narrower, fully controlled scope. You write the policy. You can control every permission we get. Our code never runs in your environment.

Least privilege, enforced by you

Read-only access to the runtime services in scope, and nothing else. Want us to see less? Scope the policy down. The grant is the contract, and you own it. The exact permissions per cloud are below.

Revocation in seconds

Incident? DR event? Vendor doubt? Remove a single grant and Kosli's access ends immediately, estate-wide.

Every access is attributable

Each session appears in your cloud's audit log (CloudTrail, Azure Activity Log, Cloud Audit Logs) as a distinct Kosli principal, cleanly separated from your own activity, ready for your SIEM.

Cloud coverage

The same pattern on AWS, Azure and GCP

AWS is where we would build first. The Azure and GCP designs are the equivalents we believe map, and we want your feedback on them before we commit to building anything.

AWS (First target)

The design we would build first. The rest of this page describes it in detail.

The grant

A read-only IAM role per account, trusting Kosli's AWS principal, bound to your unique ExternalId. Confused-deputy protection is built into the trust policy.

Estate-wide onboarding

Optionally one hub role that chain-assumes across your AWS Organization, with member accounts auto-discovered via the Organizations API.

Runtimes covered

ECS, EKS and Lambda, plus opt-in S3 bucket metadata.

Attribution in your logs

Every call appears in CloudTrail as a distinct Kosli session with your ExternalId, ready for your SIEM.

Revocation

Remove one trust statement and access ends immediately, estate-wide.

The on/off switch

The AWS tags your teams already apply.

Managed vs self-managed

What runs inside your boundary?

With Managed Capture, nothing: you grant read access and we operate the capture from our infrastructure. Self-managed inverts that: one collector stack runs inside your boundary, in an account you equip with the IAM roles and network access to reach the areas the managed service can't, holding a Kosli API token and pushing snapshots to us. Discovery works the same way, driven by your tags; the configuration and operation are yours. That's the right tool where nothing outside can reach: private-only endpoints, runtimes outside the cloud, or accounts where policy rules out third-party access. Here's how the two models compare.

Managed Capture Self-managed Capture
Kosli credential stored in your account None An API token, stored and rotated in your secrets manager
Kosli software running in your account None One collector stack in an account you operate, plus the IAM roles and network access it needs to reach your workloads
Access Kosli holds Read-only, scoped by a grant you control None (you push data to us)
Cutting Kosli off Remove one grant, effective immediately Delete the collector stack and revoke its API token
Audit log attribution Distinct Kosli session on every call Blends into your own principals
Patching and upgrades Operated and upgraded by Kosli Your team redeploys on our release cadence
Freshness monitoring Built in, with bounded staleness alerting Observability and alerting you need to build

Kosli credential stored in your account

Managed Capture

None

Self-managed Capture

An API token, stored and rotated in your secrets manager

Kosli software running in your account

Managed Capture

None

Self-managed Capture

One collector stack in an account you operate, plus the IAM roles and network access it needs to reach your workloads

Access Kosli holds

Managed Capture

Read-only, scoped by a grant you control

Self-managed Capture

None (you push data to us)

Cutting Kosli off

Managed Capture

Remove one grant, effective immediately

Self-managed Capture

Delete the collector stack and revoke its API token

Audit log attribution

Managed Capture

Distinct Kosli session on every call

Self-managed Capture

Blends into your own principals

Patching and upgrades

Managed Capture

Operated and upgraded by Kosli

Self-managed Capture

Your team redeploys on our release cadence

Freshness monitoring

Managed Capture

Built in, with bounded staleness alerting

Self-managed Capture

Observability and alerting you need to build

Mixed estates are first-class: managed where a read-only grant is easy, self-managed where you need compute inside the boundary, both reporting into the same Kosli environments.

Feedback wanted

Would this work in your organization?

This is everything your internal reviews would need to approve for the AWS preview. We want to hear if any of it wouldn't fly in your organization.

REQ 01

A read-only IAM role per account

Deployed by you. Trusts Kosli’s AWS principal, bound to a Kosli-generated ExternalId unique to your organization. Alternatively: one role in a hub account that chain-assumes across your AWS Organization, with member accounts auto-discovered via the Organizations API.

REQ 02

For R&D Validation

Narrowly scoped AWS API read permissions

List/Describe across ECS, EKS and Lambda, plus S3 bucket metadata for buckets you opt in. For S3 content fingerprinting our planned approach reads checksum metadata only; object contents never leave your account.

REQ 03

For Kubernetes Support

EKS: view access plus a reachable endpoint

Clusters need API or API_AND_CONFIG_MAP auth mode and an access entry granting AmazonEKSViewPolicy (read-only, deployable via Terraform). Public endpoints can be allowlisted to Kosli’s stable, published egress IP ranges in publicAccessCidrs. This is the one per-cluster step in the design, a single access entry applied once in code. Clusters we can’t reach this way fall back to self-managed Capture.

REQ 04

Your Kosli Capture configuration

Target account list, regions, tag filters, environment naming and cadence will be stored and versioned on Kosli’s side. Manageable through the UI, API and Terraform provider.

Scope and limits

Initial preview scope

These are the constraints we would place on a first phase.

Constraint

Private-only EKS endpoints stay self-managed

A cluster endpoint that's unreachable from outside your VPC can't be read by the managed service. Those clusters fall back to self-managed Capture, a collector stack you place where it can reach them, and the managed service reports them as explicit, named coverage gaps, never as silence. Private-only AKS and GKE endpoints would share the same constraint. We're exploring private connectivity options and would value your input on what would work in your network.

Constraint

AWS first. Azure and GCP under exploration.

The initial service would cover ECS, EKS, Lambda and opt-in S3 on AWS. The Azure and GCP patterns above are proposals, not commitments; multi-cloud demand directly shapes whether and when we build them. Tell us what your estate needs.

Position

Isolation options for regulated estates

For customers on dedicated Kosli deployments, Managed Capture runs single-tenant with hard isolation: your capture workload, config, and role credentials never share infrastructure with another customer's.

Questions security teams ask

The details behind the model

What exactly can Kosli see?

Runtime metadata: which services, tasks, pods, functions and image digests are running, where, and since when. The same information your own operators see in Describe/List API calls. We don't read application data, environment-variable contents, or S3 object contents. For opt-in S3 fingerprinting, our planned approach uses checksum metadata, so objects are never downloaded.

How do we control what's in scope?

Twice over. The IAM policy is the hard boundary: if the role can't read it, Kosli can't see it. Within that, the tag filters you define (include/exclude tags) control which discovered resources are tracked and how they map to Kosli environments.

What happens when you can't reach us?

That's the point of server-side freshness assurance: a revoked role, a network change, or a failure on our side all surface as an alert within a bounded window, to you and to us, instead of masquerading as "no changes." Today, with self-hosted collectors, that failure mode is silent unless you've built your own alerting.

Where does the captured data go, and who can see it?

Snapshots land in your Kosli org like any other environment report. Configuration (account IDs, role ARNs, regions, tag filters) is stored encrypted on our side and versioned. On dedicated deployments this is single-tenant with customer-held KMS keys.

Is the role ARN or account ID sensitive?

No. The trust policy on your side plus the Kosli-generated ExternalId (confused-deputy protection) means a leaked ARN or account ID can't be leveraged by anyone else. There are no shared secrets to rotate.

Can we run both modes at once?

Yes. Managed for the accounts where a read-only role is easy, self-managed where you need compute inside the boundary (private-only EKS, or workloads outside the cloud entirely). Both report into the same Kosli environments with identical naming, so mixed estates are first-class.

What about Azure and GCP?

The proposed designs are in the cloud coverage section above: a Reader role assignment for Kosli's multi-tenant Entra ID application on Azure, and a read-only IAM binding for Kosli's service account on GCP. Both follow the same principle as AWS. You grant narrow read access, we store no credentials in your estate, and revocation is one change on your side. Neither is committed yet; if you need one of them, that's exactly the feedback we're asking for.

Help us decide whether to build this

We're asking five questions before we write a line of code

Would your security organization approve a cross-account read-only role for this purpose, and what would that review involve?

How long would it realistically take to get from "yes in principle" to a role deployed across your accounts?

Which runtimes matter most in your estate: ECS, EKS, Lambda, S3? Are your EKS endpoints public, allowlisted, or private-only?

Would Managed Capture change how quickly, or whether, you'd roll out Runtime Evidence across your estate?

Do you need Azure or GCP coverage for this to be worth adopting?

Book a 30-minute feedback session Send us written feedback
Early access / Concept preview

Concept preview for customer feedback. Not a committed roadmap. © Kosli 2026