Skip to content
SkiMasque

Give network access an identity.

Traditional network access often starts with:

“Where are you connecting from?”

SkiMasque starts with:

“Who or what is requesting access?”

Identity and request context

Developer

developer: alice

Coding agent

actor: alice · kind: agent · revocable session

CI kind

kind: ci · verified OIDC claims

Repository

repository: acme/widget

Workflow

workflow: deploy-production

Ref

ref: main

Application

application: terraform

Workload

repository: acme/widget · workflow: deploy-production · ref: main · application: terraform

Identity is not authorization

Authentication answers:

Who are you?

Authorization answers:

What may you access?
  1. Request
    evaluatedcontrol plane
  2. Policy
A request is evaluated by the policy.
  • matchactive
    Allow
  • no matchdenied
    DenyNo matching allow rule means DENY.
If a policy matches the request, access is allowed. With no matching allow rule the request is denied.

GitHub Actions

  1. GitHub Actionsacme/widget
    OIDCcontrol plane
  2. Identity
    policycontrol plane
  3. Policy ACCESS GRANTED
  4. Session20 min
    active
  5. Gateway
    active
  6. Databasedb.prod:5432
A GitHub Actions job proves its identity with OIDC, SkiMasque evaluates the policy, and an active session carries its traffic through the gateway to the private database.

Developer identities

  1. Developer
  2. CLIskimasque connect db.prod:5432
    proves identitycontrol plane
  3. Identity
    checkedcontrol plane
  4. Policy
    active
  5. Sessiontemporary ACTIVE
    active
  6. Servicedb.prod:5432
A developer runs skimasque connect, the CLI proves who they are, the policy is checked, and a temporary session reaches the private service.

Identity + application

A developer running Terraform and a developer running arbitrary networking tools can represent different access requests.

alice running terraform

WHO
alice
WHAT
terraform
WHERE
db.prod:5432
LIMITS
—

versus alice running curl

WHO
alice
WHAT
curl
WHERE
db.prod:5432
LIMITS
—
The same developer and destination, with two different applications.

Policies can distinguish these contexts, but the application name is supplied by the caller. It is not authenticated proof of which program is running. Constrain destinations and verified identity claims as well.

Identity tells SkiMasque who is asking.

Policy determines what happens next.

Agent identity and delegation

Agent sessions carry the initiating user, a verified agent kind and a session id. Runtime and run-id labels are audit context, not authorization claims.

Policies without a kind apply to all kinds. Explicit agent policies can differ from developer policies; baseline denials set shared guardrails. Ending a parent ends delegated sessions. A sandbox is required to prevent direct network bypass.