Permissions & Access

Radar action items for access policies, token management, and authorization. Each item below describes the problem, why it is a risk, a concrete example of what can go wrong, and the step-by-step fix in Willow.

Token Expiration Missing

Problem. Session tokens never expire. Once a token is issued it can be used until it is manually revoked.

Why it is a risk.

• Tokens may be left in shell history, browser profiles, log lines, screen shares, or developer machines that leave the organization.
• Without expiration, you have to detect a leak before you can stop it. Expiration is a passive control that limits the window of damage.
• Long-lived tokens are usually flagged by SOC 2, ISO 27001, and customer security questionnaires.

Example. A laptop is donated to charity with the user's session token still cached in a config file. Six months later the laptop is resold and the new owner discovers the token. Because tokens never expire, the attacker has immediate access to the gateway.

How to solve it.

1. Open Admin > Settings > Security.
2. Set Token Expiration to a value that matches your policy. Common choices are 8 hours, 24 hours, 7 days, or 30 days.
3. Communicate the change before saving, users may need to re-authenticate more frequently.
4. Save and verify with one user that the new lifetime is enforced.
5. Pair this with Log Sync Missing so token-related events also reach your SIEM.

MCP Enforcement Policy Missing

Problem. Device scans discover unmanaged MCP servers but no enforcement policy is set, so the default behavior is to allow them.

Why it is a risk.

• Local MCP servers can expose files, secrets, or APIs that the user does not realize they are sharing.
• Without a policy, every new server is treated as an interesting finding rather than something the platform actively blocks or warns about.
• Different teams will reach different conclusions about whether a server is OK, leading to inconsistent behavior.

Example. An engineer installs a productivity-focused community MCP server that automatically reads the entire home directory. Willow detects it but the policy is set to allow, so users continue to use it for weeks before the security team sees the finding in a quarterly review.

How to solve it.

1. Open Admin > Settings > Security.
2. Find the Enforcement Policy section and locate MCP Servers.
3. Choose Warn if you need an observation period, or Block if you want unmanaged servers stopped immediately.
4. Save the configuration.
5. Visit Security > AI Discovery and triage any backlog of findings using the new policy.

Skill Enforcement Policy Missing

Problem. Unmanaged skills discovered on devices have no enforcement policy.

Why it is a risk.

• Skills can include scripts, prompts, and instructions that agents will follow without review.
• A malicious or careless skill can issue tool calls, exfiltrate data, or bypass guardrails that only run inside the gateway.
• Without policy, you cannot consistently say "all skills must come from our managed marketplace".

Example. A user finds a public skill that promises to "summarize all files in the project". They install it locally. The skill's instructions also tell the agent to upload a copy of the README to a third-party endpoint. With no enforcement policy, the skill keeps running.

How to solve it.

1. Open Admin > Settings > Security.
2. Set the Skills enforcement action to Warn or Block.
3. Promote any approved skills into managed Willow skills so users can still use them.
4. Document the request flow for new skills and link it from your internal wiki.

OAuth Policy Missing

Problem. OAuth authorization flows are governed by the default action, which is allow. There is no policy that decides which providers, scopes, or apps are reviewed.

Why it is a risk.

• Users may authorize third-party apps with excessive scopes (for example, full Gmail access).
• Without a policy, you cannot tell which OAuth apps were reviewed by security versus added ad hoc by users.
• A compromised OAuth app can read or write data on behalf of the user even after their session ends.

Example. A user authorizes an unfamiliar app with the mail.read scope from a phishing prompt. The app silently reads incoming mail for months because no policy gates the authorization.

How to solve it.

1. Open Admin > Settings > Security and find OAuth Policy.
2. Change the Default Action from Allow to Warn or Block.
3. Configure an explicit allowlist or blocklist for the providers and scopes that matter to your business.
4. Tell users that new third-party authorizations may require review and link the request flow.

Broad API Token

Problem. An API token is configured with the all scope, which grants every available admin and connect permission.

Why it is a risk.

• If the token leaks, the attacker has the same authority as a top-level admin.
• Audit logs cannot show which subset of capabilities a token actually needed.
• It encourages reuse of one token across multiple integrations, which makes rotation hard.

Example. A CI pipeline uses an all-scope token. The pipeline accidentally prints the token to a public log. The attacker now has admin access to the gateway because nothing limits the token's scope.

How to solve it.

1. Identify which capabilities the token actually needs (admin reads, connect reads, etc.).
2. Open Admin > API Tokens and click Create Token.
3. Pick the minimum required scopes (for example, connect:read only).
4. Update the consumer (CI, internal service, script) to use the new token.
5. Verify the consumer still works.
6. Revoke the old all-scope token from Admin > API Tokens.

Missing Machine User Credentials

Problem. A machine user does not have both a clientId and clientSecret configured under its client credentials.

Why it is a risk.

• Service-to-service automations may fall back to using a personal user's credentials, which is harder to audit and breaks when that user leaves.
• Without machine user credentials, scripts may store ad hoc tokens in environment files instead of using a managed flow.
• It is unclear who owns the integration because there is no dedicated identity.

Example. A nightly job uses a personal admin token instead of a machine user. The admin leaves the company, their account is disabled, and the nightly job silently fails for several days before anyone notices.

How to solve it.

1. Open Manage > Machine Users and select the affected machine user.
2. Click Generate Credentials (or Add Credentials) to create a new client ID and client secret.
3. Copy the secret immediately, it is shown only once. Store it in your runtime secret manager (Vault, AWS Secrets Manager, etc.).
4. Update the consumer to use the new client ID and secret.
5. Confirm the consumer authenticates successfully and emits expected audit events.
6. Document the owner of the machine user so future rotations have a clear contact.

Stale Machine User Credentials

Problem. Machine user client credentials have not been rotated for at least 90 days.

Why it is a risk.

• Machine user credentials are often baked into pipelines, container images, or long-running services. They tend to spread silently.
• A leaked credential can be hard to spot because there is no end-user to notice login anomalies.
• Many compliance standards require rotation of non-human credentials at a defined interval.

Example. A Kubernetes secret containing a machine user's clientSecret is mounted into a pod. The pod has been running for 18 months. The credential is rebuilt into ten different images before anyone notices it has never been rotated.

How to solve it.

1. Open Manage > Machine Users and select the affected user.
2. Click Rotate Credentials to generate a new client secret.
3. Roll the new secret into all consumers (CI, deployment, services). Use a brief overlap period if both secrets can be active.
4. Verify each consumer is using the new secret (look for fresh authentication events).
5. Revoke the old secret in Willow.
6. Update the rotation reminder so the next rotation happens before the next 90-day mark.