Ghostwriter v7: Safer Tokens, Scoped Access, and Better Automation

TL;DR: Ghostwriter v7 is a major step forward for authentication and automation. This release replaces user-managed JWT API tokens with opaque credentials, introduces scoped service tokens for non-human integrations, and tightens how tokens are validated and used across the platform.

The result is a simpler, safer model for automation that opens up more possibilities for LLM-driven workflows, makes operation log utilities safer to deploy with narrowly scoped credentials, and makes token management much easier to understand in day-to-day use.

Introduction

We’re excited to share Ghostwriter v7.0.0! This release is all about making automation easier to use without asking you to trade away security. If you’ve been using Ghostwriter’s API tokens for scripts, integrations, or custom tooling, v7 brings a much cleaner model for managing those credentials. And if you’ve wanted a safer way to support non-human workflows, this release gives you first-class primitives for that.

The biggest shift is that Ghostwriter now separates user-bound automation from service-bound automation much more clearly. User-managed API tokens are now opaque credentials instead of JWTs, and service principals with scoped service tokens now provide a safer path for integrations that should not act as a full user. That includes narrow, purpose-built access patterns like operation log utilities and read-only project access.

Opaque API tokens make automation easier and safer

One of the headline changes in v7 is that user-managed API tokens are no longer user-managed JWTs. They are now opaque credentials backed by hashed secrets. These credentials are Ghostwriter Access Tokens and identified by their gwat_ prefix. Token validation checks the secret against stored hashes and rejects revoked, expired, or inactive-user tokens.

That change matters for a few reasons:

• Simplified mental model — Most users do not want to think about JWT internals or deal with lengthy Base64 strings. Opaque tokens behave more like the API credentials people already expect from modern platforms: you create one, store it securely, use it where needed, and rotate it when appropriate.
• Improves token lifecycle management — Editing an API token’s expiry now rotates the token prefix, secret hash, and UUID identifier, immediately invalidating the previous credential. That means expiry changes are no longer passive metadata updates. They actively replace the credential, which is a much stronger and more intuitive security behavior.
• Improved token management — Ghostwriter now organizes API tokens and service tokens into clearer cards and now supports editing expiry dates from the profile page. It is a small UX improvement on paper, but it makes day-to-day credential management much more approachable and familiar for anyone who uses access tokens from platforms like GitHub.
• Easier identification — the opaque tokens include prefixes (e.g., gwat_ and gwst_) so you can easily identify your Ghostwriter tokens at glance.

Scoped service tokens open the door for better non-human integrations

The biggest new capability in v7 is the introduction of service principals and scoped service tokens for non-human automation. These new tokens are opaque Ghostwriter Service Tokens credentials identified by their gwst_ prefix. They have hashed secrets, expiration, revocation support, and last-used tracking. More importantly, their permissions are assigned directly to the token instead of being inherited from the creating user.

Historically, one of the hard parts of automation is deciding whether a credential should “be a user” or “be a service.” In v7, Ghostwriter makes that distinction explicit. User-bound API tokens remain appropriate when automation should act as a specific person. Service tokens now cover the cases where you want a durable integration or background process with intentionally limited permissions.

Instead of inheriting a creating user’s broad permissions, service tokens operate through scoped grants that determine which information and actions they can access. Project read access is validated through database-backed checks tied to the service token, service principal, creator status, and current project access.

The practical outcome is straightforward: integrations can now be more narrowly scoped, easier to understand, and safer to run in environments where broad user impersonation is not appropriate.

Safer oplog utilities and more room for LLM workflows

One of the most exciting parts of this release is what it enables.

Ghostwriter v7 adds operation log read and write tokens scoped to a single operation log and its entries, along with project read-only tokens that can be scoped to selected projects or to all projects the creator can access. Service tokens can also read project-related data, linked operation logs, evidence, reports, findings, observations, and public libraries, and they can call selected read-oriented GraphQL Actions when their grants allow it.

That makes oplog utilities meaningfully safer to build and deploy. Instead of handing a tool a user-like credential with broad access, you can give it a token that is constrained to exactly what it needs to work: reading and writing to one log. For teams building logging tools or analysis pipelines, that is a much better security story.

It also opens up some compelling possibilities for LLM-assisted workflows.

As more teams experiment with AI-assisted summarization, triage, enrichment, and drafting, the question is how to allow an LLM to safely interact with the platform. Scoped service tokens create a path for narrow permissions and auditable automation that can read the right project data or operate on the right log boundaries without needing full user-equivalent access. That does not solve every workflow question on its own, but it gives builders a much better foundation for responsible integration work.

In other words, you don’t need to worry about the wrong prompt or decision tree leading to an LLM doing anything destructive in your Ghostwriter database.

Wrap Up

Ghostwriter v7 is a foundational release. It makes API tokens easier to use, makes automation safer by default, and introduces a much stronger model for service-based access.

For teams building integrations, especially around operation logs and emerging LLM-assisted workflows, this release creates a much better path forward. And for everyone else, it simply makes token management easier and more secure.

Ghostwriter v7.0.0 is available as of June 3, 2026. If you are upgrading from earlier versions, be sure to review the CHANGELOG. You will need to rotate existing tokens to receive a new opaque credential. We also recommend reviewing how you are using those tokens to determine if you should switch any of them to a service token.