Access Keys & Constraints

Access keys authenticate requests to the LightPane API. Each key is an access grant that specifies which cloud accounts and services the holder can discover, with optional constraints that restrict how and from where the key can be used.

Key types

Type	Prefix	Use case	Typical lifetime
Embed	lp_em_	Web pages where viewers are not logged into LightPane	1 year
API key	lp_cli_	Scripts, CI/CD, Excel, automation	30 days
Demo	csl_dm_	Public demo pages	Indefinite

Token format

Keys are 32-byte cryptographically random values, base64url-encoded, with a type prefix:

lp_em_8Gk4lM0nO3qR5sT7uV9wX1yZ2aB4cD6eF8gH0iJ

The prefix helps identify key type at a glance and enables secret scanning tools (GitHub, GitGuardian) to detect leaked tokens.

Token storage

Raw tokens are never stored by LightPane. Only the SHA-256 hash is saved. When you create a key, the raw token is shown once and cannot be retrieved again.

Token in page source is acceptable

For embed keys, the token is visible in the HTML source. This is the same model used by:

• Google Maps API keys — visible in page source, restricted by HTTP referrer
• Stripe publishable keys — visible in client code, scoped to read-only operations
• Analytics tracking IDs — completely public, restricted by domain

Security comes from server-side constraints, not token secrecy.

Constraints

Each key can have server-side constraints that are validated on every request:

Origin restriction

Restrict the key to specific origins. The API matches the browser's Origin header — or an origin derived from Referer — against this list exactly, so list the full scheme and host of every page that embeds a pane. A parent domain does not cover its subdomains, and wildcards are not supported:

{
    "allowed_origins": [
        "https://status.acmecorp.com",
        "https://dashboard.acmecorp.com"
    ]
}

Browsers set Origin themselves and page JavaScript cannot change it, so this does stop someone lifting your key and calling the API from their own site in a browser. It is not a boundary against anything else: curl, Postman or any script can send whatever Origin it likes, and we have tested that they can. Treat origin restriction as hygiene that keeps a key working where you put it — what actually limits the damage if a key leaks is its service and cloud-account scoping, below.

Origin restriction does nothing for iframe embeds

An iframe embed loads a page from lightpane.io, so its request to our API carries Origin: https://lightpane.io — the iframe's own origin, never the origin of the page framing it. Two consequences:

• A key restricted to https://wiki.example.com will be refused when used in an iframe embed on that very page.
• A key that permits https://lightpane.io so the iframe works will then accept requests from any page in the world that frames it.

Origin restriction is only meaningful for script embeds, where the request comes from your own page. That is why it is off by default.

IP restriction

Restrict the key to specific IP addresses or CIDR ranges:

{
    "allowed_ips": ["203.0.113.0/24", "198.51.100.42"]
}

Useful for CI/CD runners and automation scripts running from known infrastructure.

Rate limiting

Limit requests per minute:

{
    "rate_limit_rpm": 30
}

Batch size limit

Limit the number of services per request:

{
    "max_batch_size": 5
}

Require Referer

Block requests that do not include a Referer header:

{
    "require_referer": true
}

Only the header's presence is checked, never its value. This is a weak signal and we do not recommend relying on it:

• It does not block curl or Postman. They can send a Referer header as easily as any other, and in testing they did.
• With a script embed it can break a page that would otherwise work: if the site hosting your pane sends Referrer-Policy: no-referrer, the browser omits Referer and we refuse the request.
• With an iframe embed it always passes, because the framed page is served by us with a referrer policy we set — so it tells you nothing about who framed it.

Defence in depth

Multiple layers protect against misuse, even if a token is exposed:

Layer	What it prevents
Origin check (script embeds only)	A lifted key being used from another site in a browser
Rate limiting	Bulk data extraction, cost amplification
Service scoping	Discovery of services the key should not access
Cloud binding scoping	Access to cloud accounts the key is not bound to
Monitoring and revocation	Alert on unusual patterns, one-click revoke
Token rotation	Create a new key and revoke the old one at any time

Scope

Each key has two scope dimensions:

Cloud bindings — which cloud accounts (AWS accounts, GCP projects, Azure subscriptions) the key can access. A key can only access accounts selected at creation time, which must be a subset of the creator's linked accounts.

Service scope — which services the key can discover. ["*"] for all services, or a specific list:

{
    "allowed_services": ["ec2", "s3", "lambda_functions"]
}

Key lifecycle

• Create: In the LightPane app or via the Key Management API
• Use: Include in Authorization: Bearer header or SDK accessKey config
• Monitor: Check last_used_at in the key list
• Revoke: Immediate — stops all requests using this key
• Rotate: Create a new key, update your page/script, revoke the old key