SAS account
SAS account · Type
A service account as a script holds it: through mash.sas, or a service account chosen in an automation’s settings (mash.config).
WHY A HANDLE AND NOT THE MODEL. A script used to get the raw ServiceAccount model, and a model hands over everything: a storage account’s extra (S3 secret, Entra app key, Azure account key) and Google’s key file to any author who could pick it in a config field, sandboxed or not, and every framework method besides. Since 2026-10-02 raw models are locked to scripts (AccessMap::modelHidden, ModelAccessGuard), which also locked out what a mash account is for: holding a credential FOR scripts — the Gemini extraction automation reads its API key from password and its options from data, and the documented database pattern is
creds = mash.sas.get(“Orders DB”) db = mash.db.client(“sqlsrv://{{creds.username}}:{{creds.password}}@host:1433/Orders”)
So this handle draws the line by the account’s TYPE: - a mash account (a credential made for scripts): id, uuid, type, description, username, password and data are readable; - any other type (a storage or app registration): identity only — id, uuid, type, description, username. Never its secret. Writes (username, password, data, description) and push()/save() only on a handle from mash.sas, which is itself refused to a sandboxed run.
It prints as its id, so it can be passed wherever an account id is taken (the mash.ixs clients resolve an account from a string), and serialises without the secret, so logging one does not leak it.
Methods
Section titled “Methods”account.push() → boolSave changes made to this service account (from mash.sas only).
account.save() → boolSave changes made to this service account (from mash.sas only).
toArray
Section titled “toArray”account.toArray() → arrayGet the account as an array, without its secret.