Configure resources and authentication

Workflow

Create a resource in the local console, choose a supported protocol, and enter the fixed address and ordinary settings. Account and authentication live in one resource; passwords, tokens and private keys are write-only to the OS credential store. Use the relevant connection test after saving.

Boundary and checks

Resource changes invalidate approvals bound to an older snapshot. Hide target addresses, accounts, fingerprints and business data before sharing evidence.

What a resource records

A resource holds its name, type, address, account, protocol settings, authentication and purpose labels together. You may save a draft with only a name; connection testing then identifies missing settings. Environment labels distinguish development, test and production without duplicating a credential. Account, address and notes are readable metadata, so review screenshots and exports before sharing them.

Create and test

1. In the local console, open Resources, choose a connection type and enter its address, account and protocol settings.
2. Write a password, token or private key in Authentication. Neither Web nor MCP can read it back; the OS credential store holds the secret and SQLite holds references and state.
3. When complete, run Test connection. SSH authenticates and disconnects, HTTP sends only HEAD, and databases use a fixed read-only check. A successful test does not approve a business operation.
4. When creating a task from the resource, review its copied target and credential slots. The task retains an independent snapshot; later resource edits do not silently change it.

For first-time SSH use, verify the host key independently. Prefer full TLS validation for production databases and HTTPS for authenticated HTTP. A failed credential write can leave a draft resource; inspect it and retry the write instead of duplicating the resource.

Changes and cleanup

Secret rotation, target edits or task changes invalidate authorizations bound to earlier versions. Do not disable TLS, host-key checks or target permissions to make a test pass. Clear disposable credentials after evaluation and inspect related authorizations and history. Next: approvals · troubleshooting.