01
build anywhere
Use the agent your team already uses.
Build in Claude, Cursor, LemonCrow, or any other environment that writes code. acss does not dictate how the tool is made.
Governed runtime for agent-built internal tools
The cloud for the tools your teams build.
Turn agent-built tools into governed internal software. Deploy in one command, with SSO, role-based access, secrets, network policy, and audit logs built in.
- Private by default
- One-command deploy
- Cloud, VPC, or on-prem
DEPLOY MANIFEST
policy ready
internal application
sprint-tracker
#A417
- owner
- eng-platform
- identity
- okta-sso
- access
- viewer · editor · owner
- network
- vpc-private
- audit
- enabled · siem-export
deploy from a terminal or agent shell
$
- ✓ image built in 1.2s
- ✓ org policy attached
- ✓ live at sprint-tracker.internal.acme.com
Why acss
AI made internal software cheap to create. It did not make it safe to run.
Teams are already generating approval flows, data viewers, dashboards, and one-off scripts. Without a shared runtime, those tools become invisible infrastructure: duplicate apps, scattered credentials, unclear owners, and no reliable answer to who can access what.
acss turns every small tool into a known, owned, access-controlled service — without sending the builder through a ticket queue or asking the platform team to invent another deployment path.
How it works
From local folder to governed internal URL.
No bespoke pipeline. No new console to learn. No public URL by accident.
02
deploy once
Run one command from the repo.
acss deploy ./tool packages the app and gives it an internal address. The same action works from a human terminal or an agent shell.
03
govern automatically
Apply the guardrails on first deploy.
Identity, scoped roles, network policy, secrets, ownership, and audit logging attach before the tool goes live.
“Small software should be as easy to share with your colleagues as a Google Doc — and as governable as everything else your company runs.”Pete Koomen, on why we're building acss
Built for platform and security teams
The difference is what happens after “publish.”
App builders optimize for getting something online. acss optimizes for running it inside a company.
Typical app builder
acss
Primary job
Help an individual publish an app
Help a company run internal software
Identity
A separate app account
Your existing SSO and directory
Exposure
A link that can be shared
Internal and private by default
Ownership
Whoever happened to build it
A named owner and accountable team
Controls
Added after the app is live
Applied as part of the deploy
Auditability
Limited app-level history
Deploys, access, and changes recorded
Security is not an add-on
The security review is built into the runtime.
Every deploy starts with the controls your platform team would otherwise have to assemble by hand.
sso / scim
Use company identity
Authenticate through Okta, Azure AD, or Google Workspace. Joiners and leavers follow the directory you already manage.
rbac
Scope access from day one
Every tool starts with viewer, editor, and owner roles — granted to people or groups, not whoever has the link.
audit log
See every material action
Deploys, permission changes, and access events become a durable trace that can be exported to your SIEM.
network
Keep tools off the public internet
Run in our cloud, your VPC, or fully on-prem and air-gapped. Public exposure is an explicit decision, never the default.
policy as code
Apply policy to every deploy
Attach organization-wide rules for residency, approved integrations, retention, and networking to every tool automatically.
secrets
Keep credentials out of code
Inject credentials for internal systems at runtime. They never need to live in the repository or an agent's prompt history.
Design partner program
Let teams ship small software.
Keep security in control.
We're onboarding a small group of companies already running Okta, Azure AD, Google Workspace, or an internal SSO. Tell us where agent-built tools are showing up in your organization.