Identity and Access Engineering
Design authentication, session, authorization, tenant-isolation, recovery, and identity-lifecycle behavior using standards-based, testable, and auditable controls.
A focused method your agent applies to a specific problem or piece of work.
Ask your connected agent for an outcome. It finds relevant methods and business context.
- What you get
- What to bring
- user and account model
- tenant or organization model when applicable
- client types and trust boundaries
- authentication requirements and supported identity providers
- authorization requirements and resource ownership rules
- session and token constraints
- recovery and account-linking requirements
- provisioning/deprovisioning requirements
- security, privacy, compliance, and audit requirements
- migration constraints from existing identity systems
How it works 3 steps
A typical way this skill turns context into a useful result. The exact choices depend on your task.
- 01
Frame the task Input Your goal and relevant context→Output A focused starting point
- 02
Apply the skill Input The focused starting point→Output A draft or recommendation
- 03
Review and refine Input The draft or recommendation→Output A result ready to use
↶ Review, learn, and revisit an earlier step when needed.
Decision rules
- Never invent cryptographic primitives, password hashing schemes, token formats, or simplified versions of established authentication protocols. - Do not assume one authentication flow or token strategy is correct for every client type. - Minimize credential and token lifetime based on threat, usability, and operational constraints rather than a universal duration. - Do not place secrets in client-readable tokens or rely on token opacity when the format is actually inspectable. - Validate identity assertions, redirects, issuer/audience or equivalent trust properties according to the current protocol and provider requirements. - Derive tenant context from authenticated identity or trusted server-side state, not arbitrary client-supplied tenant identifiers. - Enforce authorization at every authoritative resource boundary; UI hiding is not access control. - Account recovery must not become a weaker alternate login path. - Identity lifecycle events such as deprovisioning, role removal, and tenant removal must have explicit session/token invalidation behavior. - Break-glass access, if required, must be narrowly scoped, strongly protected, and audited. - Prefer incremental authorization complexity. Use simple role models until attributes or relationships solve a demonstrated requirement. - Preserve human approval for highly privileged grants, destructive identity changes, or exceptional recovery when system risk warrants it.
Guardrails
- Never invent cryptographic primitives, password hashing schemes, token formats, or simplified versions of established authentication protocols. - Do not assume one authentication flow or token strategy is correct for every client type. - Minimize credential and token lifetime based on threat, usability, and operational constraints rather than a universal duration. - Do not place secrets in client-readable tokens or rely on token opacity when the format is actually inspectable. - Validate identity assertions, redirects, issuer/audience or equivalent trust properties according to the current protocol and provider requirements. - Derive tenant context from authenticated identity or trusted server-side state, not arbitrary client-supplied tenant identifiers. - Enforce authorization at every authoritative resource boundary; UI hiding is not access control. - Account recovery must not become a weaker alternate login path. - Identity lifecycle events such as deprovisioning, role removal, and tenant removal must have explicit session/token invalidation behavior. - Break-glass access, if required, must be narrowly scoped, strongly protected, and audited. - Prefer incremental authorization complexity. Use simple role models until attributes or relationships solve a demonstrated requirement. - Preserve human approval for highly privileged grants, destructive identity changes, or exceptional recovery when system risk warrants it.
Example outcome request
Describe the result you need and add your team's context. Your connected agent finds the methods that fit.
I want this outcome: Design authentication, session, authorization, tenant-isolation, recovery, and identity-lifecycle behavior using standards-based, testable, and auditable controls.
Use my team's shared skills, workflows, and business context through Popasoda to find the relevant methods. Consider Identity and Access Engineering (identity-access-engineering) if it fits the goal. Ask for missing context before starting, and follow the chosen methods' review gates and guardrails.
Relevant guardrails for this method: - Never invent cryptographic primitives, password hashing schemes, token formats, or simplified versions of established authentication protocols. - Do not assume one authentication flow or token strategy is correct for every client type. - Minimize credential and token lifetime based on threat, usability, and operational constraints rather than a universal duration. - Do not place secrets in client-readable tokens or rely on token opacity when the format is actually inspectable. - Validate identity assertions, redirects, issuer/audience or equivalent trust properties according to the current protocol and provider requirements. - Derive tenant context from authenticated identity or trusted server-side state, not arbitrary client-supplied tenant identifiers. - Enforce authorization at every authoritative resource boundary; UI hiding is not access control. - Account recovery must not become a weaker alternate login path. - Identity lifecycle events such as deprovisioning, role removal, and tenant removal must have explicit session/token invalidation behavior. - Break-glass access, if required, must be narrowly scoped, strongly protected, and audited. - Prefer incremental authorization complexity. Use simple role models until attributes or relationships solve a demonstrated requirement. - Preserve human approval for highly privileged grants, destructive identity changes, or exceptional recovery when system risk warrants it.