Cisco has launched Security Cloud Control, a unified, cloud-native management platform that centralizes firewalls, multicloud defense, secure access, and security policy into a single control plane accessible at security.cisco.com. It is the formal evolution of Cisco Defense Orchestrator, and it ships with role-based access for both human administrators and API-only programmatic clients. The more important story for engineering leaders is not what this does today, but what it signals about where enterprise infrastructure control is heading.
What Changed in Security Cloud Control
- •Unified control plane: ASA firewalls, Threat Defense, IOS devices, and multicloud defense are now managed from a single cloud-hosted interface instead of separate tools.
- •AI-driven automation layer: Real-time threat detection, policy enforcement, and cross-platform telemetry are built into the platform rather than bolted on as add-ons.
- •API-only user roles: Organizations can provision programmatic clients with scoped, fine-grained permissions over firewall and security policy, separate from human administrator accounts.
Why This Matters for Agent Developers and AI-Ops Teams
Most teams today give AI agents one of two things: direct cloud credentials (too broad, ungovernable) or bespoke integration scripts (brittle, unauditable). Security Cloud Control's architecture points at a third path: a vendor-supported, RBAC-enforced control plane where both humans and agents operate through the same policy surface, the same audit log, and the same approval workflows. As Google Cloud CEO Thomas Kurian put it:
As AI systems move from copilots to agents that can take actions, the real opportunity is in building unified control planes where software agents and human operators can jointly manage core infrastructure. This means exposing policy, telemetry, and automation in a way that lets AI safely execute routine changes at machine speed while humans focus on validating intent, handling exceptions, and governing risk.
— Thomas Kurian, CEO, Google Cloud That is precisely the abstraction Security Cloud Control is building. The engineering decision in front of you is whether to treat this platform as a passive firewall UI or as the canonical agent-to-infrastructure contract for your organization's security posture. Microsoft Azure CTO Mark Russinovich reinforced why the human-plus-agent framing matters more than full automation:
AI is going to change how infrastructure is run, but it will not happen by swapping out humans for machines. The most successful organizations will be the ones that design their operations so that human experts and AI agents can collaborate on the same platform, sharing context and intent in real time to keep critical systems resilient, secure, and continuously optimized.
— Mark Russinovich, Chief Technology Officer, Microsoft Azure The implication: design your operations for collaboration first, autonomy second.
Step 1: Provision an API-Only Agent Identity in Security Cloud Control
The first concrete action is to stop sharing human administrator credentials with any automated system and start treating agent identity as a first-class provisioning problem. Security Cloud Control's role-based administration explicitly supports API-only users, meaning you can create a non-human principal with scoped permissions over specific device groups or policy domains. Pair this with Skyfire's verified identity layer so your agent carries a cryptographically attested identity token alongside the Security Cloud Control API key. Skyfire issues agent credentials that are verifiable by downstream services, which means your audit log can distinguish between "this change came from agent-id:infra-remediation-prod-7" and "this change came from a generic service account."
1// Skyfire SDK: register agent identity for Security Cloud Control integration
2import { SkyfireClient } from "@skyfire/sdk";
3
4const skyfire = new SkyfireClient({
5 agentId: "infra-remediation-prod-7",
6 scope: ["security_policy:read", "firewall_rule:write"],
7 attestation: process.env.SKYFIRE_ATTESTATION_KEY,
8});
9
10const agentCredential = await skyfire.identity.provision({
11 targetPlatform: "cisco-security-cloud-control",
12 roleBinding: "api-only-operator",
13 ttl: 3600, // 1-hour token lifetime, rotate automatically
14 auditLabel: "policy-remediation-agent",
15});
16
17console.log(agentCredential.token); // pass to SCC API calls1{
2 "agentId": "infra-remediation-prod-7",
3 "token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...",
4 "scope": ["security_policy:read", "firewall_rule:write"],
5 "issuedAt": "2026-06-03T09:00:00Z",
6 "expiresAt": "2026-06-03T10:00:00Z",
7 "attestation": {
8 "verified": true,
9 "issuer": "skyfire-trust-authority-v2",
10 "bindingPlatform": "cisco-security-cloud-control"
11 }
12}Step 2: Execute a Scoped Policy Change with Full Audit Trail
Once your agent has a verified identity and a scoped Security Cloud Control API-only role, you can execute infrastructure changes at machine speed without losing traceability. The critical design choice here is that every change request flows through the same RBAC surface a human would use, which means it is subject to the same approval rules, the same change log, and the same rollback mechanisms. Use Skyfire's transaction layer to attach a payment-authorized or approval-gated wrapper around the API call, so changes above a defined blast-radius threshold require explicit human confirmation before execution. This is the guardrail pattern Kurian describes: agents execute routine changes autonomously, humans validate intent for exceptions.
1// Execute a firewall policy update through SCC with Skyfire audit wrapping
2import { SkyfireClient } from "@skyfire/sdk";
3import axios from "axios";
4
5const skyfire = new SkyfireClient({ agentId: "infra-remediation-prod-7" });
6
7// Skyfire checks blast radius before allowing execution
8const approval = await skyfire.actions.requestApproval({
9 action: "firewall_rule_update",
10 target: "device-group:prod-east-dmz",
11 changeDescription: "Block inbound TCP 8080 from 0.0.0.0/0",
12 blastRadiusEstimate: "low", // agent-computed; high triggers human review
13 credential: agentCredential.token,
14});
15
16if (approval.status === "approved") {
17 const sccResponse = await axios.put(
18 "https://security.cisco.com/api/rest/v1/policies/firewall-rules",
19 {
20 deviceGroup: "prod-east-dmz",
21 rule: {
22 action: "DENY",
23 protocol: "TCP",
24 destinationPort: 8080,
25 sourceNetwork: "0.0.0.0/0",
26 description: "Agent-remediated: inbound 8080 block",
27 },
28 },
29 {
30 headers: {
31 Authorization: `Bearer ${agentCredential.token}`,
32 "X-Skyfire-Audit-Id": approval.auditId,
33 "X-Skyfire-Agent-Id": "infra-remediation-prod-7",
34 },
35 }
36 );
37}1{
2 "approvalId": "appr_9xKm2pQr4TvL",
3 "status": "approved",
4 "blastRadiusEstimate": "low",
5 "approvedBy": "auto-policy-engine",
6 "auditId": "audit_3dNw8sYq1ZcM",
7 "changeExecuted": {
8 "platform": "cisco-security-cloud-control",
9 "deviceGroup": "prod-east-dmz",
10 "ruleId": "rule-00471",
11 "status": "applied",
12 "appliedAt": "2026-06-03T09:04:22Z"
13 }
14}Step 3: Wire Observability So Every Change Is Agent-Attributable
The last step is the one most teams skip until something goes wrong. Security Cloud Control provides deep cross-platform telemetry across your security stack, but that telemetry is only useful for agent governance if you can distinguish agent-initiated changes from human-initiated ones at query time. Instrument your observability pipeline to tag every SCC event with Skyfire's agent attribution metadata, then route agent-originated changes to a dedicated review queue.
1// Stream SCC change events into observability pipeline with agent attribution
2import { SkyfireClient } from "@skyfire/sdk";
3
4const skyfire = new SkyfireClient({ agentId: "infra-remediation-prod-7" });
5
6async function handleSCCChangeEvent(event: SCCChangeEvent) {
7 const enriched = await skyfire.observability.enrich({
8 eventId: event.changeId,
9 platform: "cisco-security-cloud-control",
10 rawEvent: event,
11 agentId: "infra-remediation-prod-7",
12 auditId: event.headers["X-Skyfire-Audit-Id"],
13 });
14
15 // Route agent-originated events to dedicated governance queue
16 if (enriched.originType === "agent") {
17 await observabilityPipeline.emit("agent-infra-changes", enriched);
18 } else {
19 await observabilityPipeline.emit("human-infra-changes", enriched);
20 }
21}1{
2 "eventId": "scc-evt-00892",
3 "originType": "agent",
4 "agentId": "infra-remediation-prod-7",
5 "auditId": "audit_3dNw8sYq1ZcM",
6 "platform": "cisco-security-cloud-control",
7 "changeType": "firewall_rule_update",
8 "deviceGroup": "prod-east-dmz",
9 "timestamp": "2026-06-03T09:04:22Z",
10 "attribution": {
11 "verifiedIdentity": true,
12 "skyfireAttested": true,
13 "humanReviewRequired": false,
14 "rollbackAvailable": true
15 }
16}What to Test Before Shipping
- •Identity isolation: Confirm that your agent's API-only role in Security Cloud Control cannot escalate to device console access or modify other device groups outside its assigned scope. Test with an intentional out-of-scope call and verify rejection.
- •Blast radius gating: Trigger a simulated high-blast-radius change (for example, a rule touching all device groups) and verify that Skyfire's approval layer routes it to a human review queue rather than auto-approving.
- •Agent attribution in audit logs: Pull 24 hours of SCC change events and confirm that every agent-originated change carries a distinct Skyfire audit ID that is queryable separately from human-initiated changes. If you cannot filter the two apart, your observability wiring is incomplete.
Where This Is Heading
Platforms like Security Cloud Control are quietly defining the enterprise control plane for the next decade. The Cisco Security Cloud combines XDR, hybrid mesh firewall, and multicloud networking into a single policy surface. That is not just a UI consolidation play; it is the API contract through which AI agents will eventually manage critical infrastructure at scale. The engineering leaders who win in this environment are not the ones who wait for agents to become more capable. They are the ones who do the boring platform work now: standardizing on a central control plane, defining RBAC schemas with non-human operators in mind, and treating agent identity as seriously as they treat service accounts today.
Skyfire's role in this stack is specific and non-overlapping with what Cisco provides. Cisco owns the infrastructure policy surface. Skyfire owns the agent identity layer and the transaction/approval wrapper that makes it safe to let an agent touch that surface autonomously. Together, they give you the three things you need to run agentic infrastructure operations responsibly: verified identity, scoped credentials, and a complete audit trail. Start building toward that combination now, before the first production incident makes the architecture decision for you.
Ready to power your agents with real credentials?
Join teams using Skyfire’s trust stack to enable secure transactions and authenticated API access for AI agents across the internet.
Read More Blog Posts
Skyfire vs Stripe: Agent Identity and Payment Infrastructure for AI Workflows
AI agent developers need both verified identity and payment capabilities to build autonomous systems that can authenticate themselves and execute real transacti
Build AI agents that authenticate and charge across external services
AI agents need verified identity and payment credentials to execute real transactions across external APIs without authentication failures or blocked checkouts.