# Konnect Access Scope > Troubleshoot Konnect operator access and visibility. Use when a user cannot authenticate, cannot see or edit a Konnect resource, may be in the wrong region, org, or team, or needs help with scoped roles or IdP-managed access. Not for Dev Portal app auth. - **Type:** Skill - **Install:** `agentstack add skill-kong-ai-marketplace-konnect-access-scope` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Kong](https://agentstack.voostack.com/s/kong) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Kong](https://github.com/Kong) - **Source:** https://github.com/Kong/ai-marketplace/tree/main/plugins/kong-konnect/skills/konnect-access-scope - **Website:** https://konghq.com ## Install ```sh agentstack add skill-kong-ai-marketplace-konnect-access-scope ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Konnect access and scope troubleshooting ## Goal Explain why an identity can or cannot reach a Konnect surface, see a resource, or mutate it, then identify the narrowest next step. Default to read-first inspection. Do not propose role or team changes until you have separated resource existence, endpoint selection, authentication, and authorization. Use this skill for operator or automation access to Konnect itself. Do not use it for downstream API consumer auth, Dev Portal application credentials, or Gateway runtime auth flows. ## Tool Selection - Use the shared `kong-konnect` MCP server first for live inspection when it is available in the session. - Use `kongctl-query` for read-only checks, identity inspection, and resource existence checks from the CLI surface. - Preserve the repository's chosen declarative toolchain when access-adjacent resources need to be codified: prefer `kongctl-declarative` for `kongctl` YAML and `terraform-konnect` for HCL-managed Konnect resources. - If the request depends on live Konnect state and `kong-konnect` MCP is not connected, say so early and continue with CLI or user-provided artifacts. Do not treat declarative config in a repo as proof that a user should be able to see or edit the live resource. Live access always wins over intended state. ## References To Load Load only the reference file that matches the active branch: - `references/region-org-and-team-checks.md` - Load when wrong region, org, team, or resource slice is the likely cause. - `references/visibility-vs-permission.md` - Load when the hard question is whether the resource exists, is visible, or is writable by this identity. - `references/idp-and-role-model.md` - Load when SSO, SCIM, IdP-managed groups, additive roles, or external identity mastering is the real boundary. ## Inspection Order ### 1. Identify the failing surface Pin down: - which interface is failing: MCP, `kongctl`, Konnect UI, Konnect API, or Portal operator UI - which operation fails: authenticate, list, get, edit, create, delete - which resource scope is involved: organization, control plane, portal, catalog asset, analytics surface, or Event Gateway resource - whether the symptom is "cannot see it" or "can see it but cannot change it" - whether the caller is a human identity or an automation identity acting directly against Konnect Keep the failing operation concrete. Access failures look similar across surfaces but have different root causes. If the complaint is really about developer-facing application registration, issued credentials, or runtime API access, hand off to `konnect-app-auth` instead of stretching this skill. ### 2. Verify endpoint and identity before permissions Confirm the caller is pointed at the right Konnect region and organization before reasoning about roles. For CLI-based checks, prefer: ```bash kongctl get organization -o json kongctl get me -o json ``` If those succeed, authentication is present. If they fail, stop there and fix auth or endpoint selection first. Load `references/region-org-and-team-checks.md` when the main ambiguity is where the caller is pointed rather than what permissions they have. ### 3. Separate resource existence from visibility Check whether the target resource exists in the organization independently of the affected user. - If an operator with broader access can see it, the issue is likely scope or role assignment. - If nobody can see it, the problem is likely name, region, organization, or resource lifecycle rather than permissions. - If the resource exists under a different product surface than expected, explain the mismatch instead of calling it a permission failure. Load `references/visibility-vs-permission.md` when the core question is whether the resource is absent, hidden, or only non-mutable. ### 4. Evaluate scope and role layering Interpret access using these defaults: - Roles are additive. Multiple team memberships can expand what a user can do. - Resource-scoped roles matter as much as organization-level roles. - A user may be allowed to read a resource but not mutate it. - Portal, analytics, gateway, and Event Gateway surfaces can expose different subsets of the same organization. - Organization-wide roles are only a starting clue; verify the narrower resource slice that actually governs the target object. Do not assume a missing mutation permission implies missing read permission, or the reverse. ### 5. Check for IdP-managed or external identity constraints When the user mentions Okta, SSO, SCIM, or IdP-managed groups, verify whether the requested change is blocked because identity membership is mastered outside Konnect. Treat externally managed identity data as read-only from the Konnect side unless you can confirm otherwise. Load `references/idp-and-role-model.md` when role layering, IdP mastery, or team/identity mapping is the main decision branch. ### 6. Explain the narrowest root cause Classify the outcome as one of: - wrong region or organization - missing or invalid auth - resource does not exist where expected - read access present but write access missing - scope mismatch between team or role assignment and target resource - IdP-managed identity constraint - neighboring product-surface confusion Then give the minimum next action needed to unblock the user. If the root cause is outside Konnect operator access, say which neighboring skill should take over instead of keeping the diagnosis open-ended. ## Konnect-Specific Gotchas - A valid PAT does not prove the caller is pointed at the intended region. - Seeing one product surface does not imply access to every Konnect surface. - Additive roles can make "why can this user do that?" as important as "why can't they?" - IdP-backed users may appear editable in theory but still be effectively read-only for team or profile changes. - "I cannot see the control plane" can mean the control plane exists in a different region, belongs to a different team scope, or was never created. ## Validation Checklist Before answering, verify that you can state: - the exact failing surface and operation - whether authentication itself works - whether the target resource exists - whether the issue is endpoint, scope, role, or IdP related - whether read and write permissions differ in this case - whether another skill should take over for the next step ## Handoffs - Use `kongctl-query` for exact read-only command selection and output shaping. - Use `kongctl-declarative` or `terraform-konnect` when the user wants to create or update managed Konnect resources after the access issue is understood. Match the repository's current toolchain. - Use `konnect-app-auth` when the real issue is developer registration, application credentials, or Dev Portal auth behavior rather than operator access to Konnect. - Use `konnect-gateway-triage`, `konnect-observability-triage`, `konnect-api-publish`, or `konnect-event-gateway` when the real problem is not access but operator ambiguity inside that surface. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Kong](https://github.com/Kong) - **Source:** [Kong/ai-marketplace](https://github.com/Kong/ai-marketplace) - **License:** MIT - **Homepage:** https://konghq.com Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-kong-ai-marketplace-konnect-access-scope - Seller: https://agentstack.voostack.com/s/kong - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.