Devin needs credentials to do real work: registry tokens, API keys, database passwords, browser logins. Secrets can live at five tiers: enterprise, org (global), repo-specific, session-specific, and personal. The highest-tier rule from Lesson 4 applies again: define each secret at the highest tier that genuinely needs it, and prefer scoped service accounts over anyone's personal credentials. This is the principle of least privilege applied to credentials: the tier is a blast radius, so a secret should be visible to exactly the sessions that need it and no more.

The classic failure mode shows why the tier matters. Someone adds a shared CI token as a personal secret. Their sessions work, so nobody notices; then a teammate's environment build fails on registry auth, because personal secrets only exist for the person who added them. The fix is to re-create the token as an org secret and delete the personal one. The sandbox at the end of this course makes you hit and fix exactly this.

Enterprise secrets reach every org, org secrets are shared by all members and environment builds, personal secrets exist only for the person who added them

Hygiene rules that keep a secret library trustworthy: rotate credentials on a schedule, use descriptive names (AWS_STAGING_DEPLOY_KEY, not KEY2), back each shared secret with a dedicated service account so it survives offboarding, and use the TOTP and site-cookie support for services Devin must log into through a browser.

Secrets are one layer of a broader posture. The others:

IP access lists restrict where the Devin app can be accessed from, so access happens only from networks you allow.
SSO enforcement makes your IdP the single door in, which is what makes the Lesson 2 provisioning model trustworthy.
Custom roles are the permission layer: least-privilege control over who can touch secrets, integrations, and settings.

AI Guardrails add a layer none of the above cover: enterprise-level screening of the messages users send to Devin, watching for prompt injection, data exfiltration, and policy violations. Each guardrail takes one of four graduated actions: log_only records the event silently, warn_user lets the message through but flags it visibly to the user, block_message stops the message, and kill_session ends the session. Every triggered guardrail lands in the audit logs as an ai_guardrail_violation event, and a violations API lets you pull them into your own monitoring. Start conservative (log_only or warn_user) and tighten once you've seen real traffic.

Finally, you're the person security review will ask, so have the data-handling answers ready: customer data is encrypted, retention is policy-bound, and your code is not used to train models that serve other customers; you own the IP of Devin's output; SOC 2 reports and audit documentation are available; and for stricter requirements, customer-managed keys and dedicated deployment options exist (see the Enterprise Deployment docs). Knowing these answers cold is often the difference between a rollout that proceeds and one that stalls in review.

Knowledge Check