This is a review guide for organization administrators evaluating and approving MCP Servers and A2A Agents before enabling them for organizational users. It provides guidelines to validate that an agentic app meets security, quality, and governance standards.

anchorTable of Contents

• Overview
• Server-Level Review
  • Identity & Provenance
  • Server Accessibility
  • Authentication Configuration
  • Privacy & Compliance
  • Badge Types (Public Apps on AppHub)
• Tool-Level Review
  • Tool Naming & Descriptions
  • Input & Output Schemas
  • Side Effects & Risk Assessment
  • Consent & Elicitation Requirements
• Enablement Scope & Assignment
  • Org vs. Group Enablement
  • Server vs. Per-Tool Assignment
• Security Review
  • Input Validation Posture
  • Authorization & Least Privilege
  • Data Handling & Privacy
  • Network & Supply Chain
  • Injection & Manipulation Defenses
• Quality Review
  • Functional Accuracy
  • Error Handling
  • Reliability & Performance
  • Documentation & Support
• Signature & Change Policy
• Approval Checklist
• Post-Approval Monitoring

anchorOverview

Your Role as Gatekeeper

As an organization administrator, you are responsible for ensuring that any agentic app enabled for your users meets your organization's security, privacy, and quality standards. Agentic apps have the ability to:

• Execute actions on behalf of users via AI agents
• Access organizational data through configured credentials
• Interact with external systems using your org's identity

Before approving an app, verify that:

1. The developer/company is legitimate and trustworthy
2. The server and its tools are secure and well-designed
3. The data handling practices align with your org's policies
4. The capabilities exposed are appropriate for your user base

Review Process

1. Browse → Discover the app in Control Hub → Management → Apps → Agentic Servers
2. Review → Evaluate the app
3. Configure → Set authentication, enable specific tools, define scope
4. Approve → Enable for your organization (org-wide or group-specific)
5. Monitor → Observe usage and re-review on changes

anchorServer-Level Review

Identity & Provenance

Verify the app's publisher is legitimate and the server is production-ready.

Badge Types (Public Apps on AppHub)

Public agentic apps are assigned a badge on AppHub indicating the level of Cisco review they have undergone:

Org-Private vs. Public:

• Org-Private apps are only visible to your organization. They have NOT undergone any Cisco/AppHub review. As the org admin, you are solely responsible for reviewing and approving these apps.
• Public apps have been reviewed by Cisco and carry a badge indicating the level of review (see table above). However, even for public apps, the org admin remains ultimately responsible for enabling the app within their organization. Cisco's review validates technical and security standards, but the decision to allow the app for your users — and the associated legal and compliance responsibility — rests with you as the org administrator.

Server Accessibility

Authentication Configuration

Ensure the authentication type is appropriate for the server's purpose and your org's security posture. Agent Central supports four auth types:

Header semantics: For userScopedToken and orgScopedToken, the credential is sent as <key>: Bearer <value>. The Bearer scheme is hard-coded; the key field controls only the header name. If the upstream server expects a non-Authorization header (e.g., X-API-Token), set key accordingly during enablement.

Credential storage: orgScopedToken.value, OAuth2.clientSecret, and OAuth2 access tokens are KMS-encrypted at rest. userScopedToken never persists a token value — it's supplied per-request by the client SDK.

Note: Legacy auth types apiKey and userToken are automatically migrated on read to orgScopedToken and userScopedToken respectively. customHeaderAuth is rejected for new server registrations but still honored on read for existing records (admin enablement writes still accept it for back-compat).

OAuth configuration prefill: For OAuth auth types, if the server exposes a .well-known/oauth-authorization-server endpoint (RFC 8414), the authorization endpoint, token endpoint, and supported scopes are automatically prefilled during enablement. If the server does not expose this endpoint, you (the admin) will need to manually fill in these OAuth configuration values.

Questions to ask:

• Does the auth type match the data sensitivity level? (Shared org credential vs. per-user identity matter very differently for audit and blast radius.)
• Are credentials rotatable? What is the rotation schedule?
• Are scopes minimal (least privilege)?
• For OAuth: Is the authorization server well-known and trusted? Are the prefilled values correct?
• For orgScopedToken: Is the stored credential KMS-encrypted and rotated regularly? Who in your org has visibility into the value?
• For userScopedToken: Is the header key appropriate for the upstream service, or is the default Authorization header sufficient?

Privacy & Compliance

Vendor-provided URLs are captured and displayed as part of server metadata. Review the following:

anchorTool-Level Review

Review each tool individually before enabling it. Tools are the primary attack surface for agentic apps.

Tool Naming & Descriptions

Why this matters: Tool descriptions are injected into LLM context. Deceptive descriptions can manipulate which tools get selected, potentially routing sensitive data to malicious servers.

Input & Output Schemas

Side Effects & Risk Assessment

Tools don't carry a formal risk-class field — you assess risk from the tool's name, description, input schema, and stated side effects. Use the buckets below as a mental model when deciding whether to enable a tool, restrict it to specific groups, or reject it.

Questions for tools you assess as high-risk:

• Does the tool description indicate a human-in-the-loop step (elicitation) before execution?
• Can the action be undone if invoked incorrectly?
• Is the scope of impact bounded (single user vs. org-wide)?
• Does the tool advertise rate limits preventing mass actions?

Consent & Elicitation

Elicitation is the developer-facing mechanism for pausing a tool call to ask the user for input or confirmation. As an admin, you can't directly configure elicitation — but you can assess whether the developer has applied it appropriately.

anchorEnablement Scope & Assignment

When you approve an agentic app, you also decide who in your org may use it and at what granularity. Two independent dimensions control this:

Org vs. Group Enablement

When you select Selected user groups, you choose the specific groups that should have access. A user's group membership is resolved from your org's identity at request time — only users whose groups intersect with the configured set are granted access.

Server vs. Per-Tool Assignment

Best Practice: Start with All tools. Move to Per-tool only when you have a concrete need to split tool access across groups — per-tool assignment requires you to maintain group lists per tool, which compounds drift risk.

anchorSecurity Review

Input Validation Posture

Verify the developer has implemented proper input handling:

Authorization & Least Privilege

Data Handling & Privacy

Network & Supply Chain

Injection & Manipulation Defenses

anchorQuality Review

Functional Accuracy

Error Handling

Reliability & Performance

Documentation & Support

anchorSignature & Change Policy

Understanding Tool Signatures

Webex computes a schema signature for each tool and continuously monitors it for changes. When a tool's current signature differs from the version you previously approved, Webex flags it: the tool's behavior may have been modified since your last review.

When Signatures Change

Configuring Signature Policy

For each tool, decide on "Allow signature change":

Best Practice: Default to Off for new/unfamiliar servers. Switch to On only after establishing trust with the publisher through multiple successful review cycles.

Runtime Behavior on Signature Drift

When a tool's live signature differs from the stored signature:

The unsecure flag is your safety net when running with Allow signature change = On: clients still receive the tool, but they're alerted that the contract has shifted since you last reviewed it.

anchorApproval Checklist

Use this checklist before enabling an agentic app.

Server Identity & Trust

• Publisher is a legitimate, identifiable company
• Company website is valid and professional
• Contact email domain matches company name
• App description clearly states purpose and capabilities
• Logo is appropriate and original (no Cisco/Webex branding misuse)
• Badge type reviewed and understood (for public apps)
• Privacy URL (privacyUrl) is publicly accessible
• Support URL (supportUrl) is valid and accessible
• For org-private apps: developer identity verified within your org

Security

• Server URL uses HTTPS with valid TLS certificate
• Authentication type is appropriate for data sensitivity
• OAuth scopes (if applicable) are minimal and well-defined
• No tool requests excessive or unnecessary permissions
• Input schemas enforce strict validation (types, bounds, patterns)
• No evidence of dynamic code execution from user input
• Tool descriptions are factual and don't contain manipulative/injection content

Tool Quality

• Tool names are clear, descriptive, and properly namespaced
• Tool descriptions are accurate, factual, and non-manipulative
• Input/output schemas are precise with appropriate constraints
• High-risk tools have human-in-the-loop (elicitation) controls
• Error handling produces structured, non-leaking responses
• Side effects are documented and appropriate for stated purpose
• No tool appears to shadow or impersonate tools from other servers

Privacy & Data Handling

• Privacy URL points to a valid, accessible policy page
• Data minimization: tools only request/return data necessary for their function
• No tool collects input fields unrelated to its stated purpose
• Cross-session data isolation: no data leakage between users or sessions
• User consent mechanisms are in place for sensitive/destructive operations

Enablement Scope

• Audience choice (Entire organization vs. Selected user groups) matches the tool's risk profile
• If Selected user groups: group list is current and reflects intended audience
• Assignment mode (All tools vs. Per-tool) is appropriate; Per-tool only used when groups genuinely differ across tools
• Allow signature change set per tool — default to Off for new/unfamiliar servers

Operational Readiness

• Documentation/support URL is valid and useful
• Version and changelog information available
• Rate limiting is in place
• Long-running operations support progress streaming
• Server demonstrates acceptable response times
• Reconnection/resume supported for streaming operations

anchorPost-Approval Monitoring

After enabling an agentic app, continue to monitor for issues.

Webex automatically detects changes in server metadata, enablement state, and tool schema signatures, and surfaces them in your admin views. You don't need to poll — the system tells you what changed.

What to Watch For

When to Re-Review

Trigger a full re-review when:

• Tool signatures change (if policy is "Off")
• Major version bump announced by the developer
• Security incident reported affecting the server or its dependencies
• Org security policy changes (e.g., stricter data residency requirements)
• User reports unexpected behavior or data exposure
• More than 6 months since last review (periodic hygiene)

Revoking Approval

If a server no longer meets standards:

1. Toggle the app to Blocked in Control Hub (immediate effect)
2. Document the reason for revocation
3. Notify affected users/groups
4. Contact the developer with specific issues for remediation
5. Re-review if/when the developer addresses concerns

anchorSummary

Effective approval requires evaluating an agentic app across four dimensions:

When in doubt, start with a restrictive posture: enable only specific tools, limit to a pilot group, keep signature change policy off, and expand access as trust is established through operational experience.