Guides

insecur is experimental and prelaunch. There is no public sign-up yet, and the hosted service is not approved for valuable production secrets. Local Mode runs the development loop with no account.

Using insecur with coding agents

To have an agent add insecur to an existing project, give it the agent quickstart. It covers accountless Local Mode, importing the intended credential, wrapping the normal command, and verifying a fresh Git worktree. The hosted session and attribution features below are optional and require hosted authentication.

Coding agents read your repo and your .env files at machine speed. insecur lets you remove plaintext development secrets from project files and attribute each runtime injection to the session that requested it.

With insecur, an agent does not need a static secret in its ambient environment. Every insecur run mints a fresh one-use audited injection grant, and every audit event carries the principal chain: which human, which agent, which command.

This is development-secret custody, not unreadability. The injected value reaches the child process the agent runs, and an agent that controls that process can inspect or print it. The current benefit is no plaintext project .env file, a short-lived single-use grant per run, and an audit record. Automatic provider rotation after an exposure is not available yet.

Launch an agent in a deny-by-default session

For hosted projects, wrap your agent harness in insecur agent shell. The child starts with a derived agent session and a filtered environment. This is not a filesystem sandbox: the agent can still access files allowed by its OS user. Local Mode does not require this command.

insecur agent shell -- claude

The -- separator is required. Everything after it is the command to run. The agent inside sees an attributed session, not your ambient credentials.

To run a different harness, swap the command:

insecur agent shell -- codex

Attribution tiers

Attribution shows up in insecur whoami and in every audit event. Higher tiers give tighter, more trustworthy provenance.

Tier	How it happens	What it means
Derived	Child credential minted from a live human session (`agent shell`)	Strongest: the agent's actions chain back to a specific human session
Registered	Tier-2 structural registration when a harness is detected (`agent register`)	Structural agent session recorded for audit
Tag-only	`--agent <name>` or `INSECUR_AGENT_TAG`	A label with no cryptographic backing
None	No attribution provided	Actions attribute to the raw principal only

Prefer derived attribution. Use agent shell so the agent's session descends from your live human session.

Wire an agent launched separately

If your harness launches outside agent shell, hand it a session two ways.

Print metadata-only shell exports for the harness to source:

insecur agent env

insecur agent register

For a headless machine, use device-authorization login that mints an agent-marked session:

insecur login --device --agent-session

Environment variables a harness may see

An agent harness may observe these. None of them is a secret value your product reads back.

Variable	Purpose
`INSECUR_SESSION_TOKEN`	Session credential, in the environment only
`INSECUR_AGENT_CREDENTIAL_FILE`	Path to a sealed derived-agent credential file
`INSECUR_AGENT_TAG`	Tag-only attribution label

Gate agents with a scan hook

Print offline recipes for wiring a scan gate into Claude Code and Codex. No auth required.

insecur guide hooks