Admin Deployment
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
We provide deployment scripts for setting up Takumi Guard across your organization's developer machines using management tools. Customize them to suit your management tool.
This feature requires an active base subscription with Guard enabled. See Pricing & Billing for details.
Overview
The setup consists of two phases:
- Preparation — Create a bot in Shisho Cloud console and download the setup script
- Deployment — Create a wrapper script for your management tool and push it along with the setup script to target machines
Tokens issued by the setup script can be viewed and managed in the Shisho Cloud console under Guard > Tokens.

Prerequisites
Before deploying, complete the following steps in Shisho Cloud console:
- Create a bot — Click the "Add Bot" button on the Settings > Bots page
- Assign the role — Select the "Takumi Guard Token Issuer" role for the bot
- Get the API key — On the bot's detail page, click "Create API Key" and save it securely
For detailed instructions on creating bots and API keys, see this guide.
Setup Script
We provide a setup script that handles token minting and package manager configuration. Download the script for your platform:
- macOS / Linux: https://shisho.dev/releases/takumi-guard-setup-0.8.1.sh
- Windows: https://shisho.dev/releases/takumi-guard-setup-0.8.1.ps1
Target machines must have curl installed (macOS and Linux).
Usage
The setup script only modifies config files for the user who runs it. To deploy across all users in your organization, use the wrapper scripts described in the Deployment Examples section.
Run the setup script as follows. Pass the API key via the TG_BOT_API_KEY environment variable:
TG_BOT_API_KEY="shisho_apikey_..." ./setup.sh <BOT_ID> <USER_IDENTIFIER>
| Parameter | Description |
|---|---|
TG_BOT_API_KEY | (environment variable) Bot API key |
BOT_ID | Bot ID from Shisho Cloud console |
USER_IDENTIFIER | A unique identifier for the device/user |
TG_DIRECT_WRITE | (Optional environment variable) Skips the package-manager pre-check and writes config files directly. See here for details. |
To limit which package managers are configured, pass the scope as the third argument.
TG_BOT_API_KEY="..." ./setup.sh BOT_ID USER_IDENTIFIER npm,rubygems
| Scope | Package managers configured |
|---|---|
npm | npm, pnpm, yarn (v2+), bun |
pypi | pip, uv, poetry |
rubygems | Bundler |
golang | Go modules |
For Poetry, the user-level configuration written by the script is not enough to enable protection. A per-repository setup is required separately. See When using the Python package manager Poetry for details.
Choosing a USER_IDENTIFIER
The USER_IDENTIFIER is an opaque string that identifies a device or user. Choose a consistent naming convention for your organization.
Constraints:
- Allowed characters:
a-z,A-Z,0-9,-,_,.,@,+ - Length: 4 to 255 characters
Here are some examples of identifiers you can use.
| Example | Value | Description |
|---|---|---|
| Device serial number + OS username | C02X1234_jdoe | Hardware serial number from the device BIOS |
| Asset management ID + employee ID | ASSET0042_EMP12345 | IDs managed by your organization |
| MDM device ID + OS username | a401c7d0_jdoe | Device ID assigned by your MDM tool |
Verify that your chosen identifier is unique within your organization. Some identifiers (e.g., serial numbers) may be empty or not unique on certain environments such as custom-built PCs or virtual machines. Use a value that reliably distinguishes each device and user.
Behavior
First run
The setup script mints a token, creates a timestamped backup of each existing config file (e.g. ~/.npmrc-backup-20260408-162351), and appends Guard settings. Existing non-Guard settings are not modified.
Cases where the token is overwritten
The setup script inspects every Guard-managed config file and validates any existing token it detects. If different tokens are present across multiple config files, every one of them is validated.
If every detected token matches one of the following conditions, the script mints a fresh organization user token and overwrites the existing tokens with the new one. On the other hand, if at least one valid organization user token bound to the specified organization is found, that token is reused.
- An email-verified token
- A token that does not exist
- A token that has been revoked
- A token issued for a different organization
A timestamped backup of each config file is created before the overwrite.