Harbor Access / 05 / PRACTICE GUIDE
Service accounts and non-human identities
Govern application, automation and AI-agent identities through ownership, purpose, federation boundaries and retirement plans.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
EVIDENCE REVIEW DESK
Move from observations to decisions.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Running but ownerless / Incomplete decision
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s => s.accountListed === trueBeing inventoried does not establish purpose or ownership. Without an owner and narrow business need, permissions cannot be justified or retirement planned responsibly.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
Non-human identities still need owners
A Harbor build job accesses an application repository. An accountable team and technical role may own it, but the identity is not a human account. Record purpose, environment, resource, permission and retirement conditions. Leaving an ownerless account because the automation still runs hides risk. Do not blindly apply human MFA workflows to service identities; assess machine authentication through appropriate keys, managed identity or federation context. Microsoft terminology is used only within its product context, not as a universal object model for all providers.
02 / EXPLANATION
Short-lived credentials need scoped trust
Federation can reduce long-lived secrets without automatically narrowing a broad trust relationship. Specify which issuer, subject and audience are accepted for the workload and environment. Trusting only an organization name can expose access to unintended repositories or workflows. Harbor reviews declared evidence for these boundaries; it obtains no real OIDC token and verifies no signature. The local policy desk is not a federation engine either. Do not treat a federation-enabled flag as an assurance result without separately reviewing trust scope and verification behavior.
03 / EXPLANATION
Rotation is a migration
Creating a new key does not end use of the old one. Plan consumers, deployment order, observation, rollback and revocation of the prior key. Keep real key values out of tickets and learning files; use secure references. Harbor asks which consumer migrated to which revision and when the old access path was checked. Even automatic rotation needs review for failed consumers and forgotten copies. The desired evidence is not merely key creation but an authorized, verified migration and termination of the prior path. This exercise generates or revokes no actual credentials.
04 / EXPLANATION
Task boundaries for agents and automation
An AI agent’s tool use still sits within workload identity and authorization boundaries. A natural-language instruction does not grant unlimited operations on data sources. Design reading, writing and approval-dependent steps separately, with task-appropriate records, consumption limits and human approval scope. Harbor assigns the agent only listed actions on a synthetic resource; the local model executes no tools. Retirement review covers workflows, federation trust and unused grants together. Business ownership must remain clear even when software selects its next step dynamically.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.