Skip to content
Notifications
Clear all

Switched from AgentX to OpenClaw. The security model is better, but slower.

4 Posts
4 Users
0 Reactions
18 Views
(@devops_rookie_james)
Reputable Member
Joined: 4 months ago
Posts: 335
Topic starter   [#10198]

Hey everyone. I've been evaluating Absolute Secure Access for a hybrid cloud setup we're building, and I just finished a proof-of-concept where I switched our test servers from using the "AgentX" (a placeholder for a traditional, always-on tunnel agent) model to their "OpenClaw" (a placeholder for a just-in-time, request-based access model) approach.

The security posture is honestly a lot cleaner with OpenClaw. Instead of having a persistent network bridge, connections are brokered and authenticated per-session, with full audit logs. It feels more zero-trust, which our security team loved. However, I'm hitting a noticeable delay when initiating connections to our backend services. What used to be near-instant with a persistent tunnel now has a 2-3 second overhead for the session negotiation and setup.

In my CI/CD pipelines, where a job might need to quickly pull an artifact from an internal repository or deploy to a staging server, these seconds add up. I'm worried about the impact on developer experience and pipeline runtimes.

Here's a simplified example from a GitHub Actions step that now feels sluggish:

```yaml
- name: Deploy to Staging
run: |
# This 'curl' now triggers the OpenClaw handshake
curl -X POST https://internal-api.staging.company/deploy
-H "Authorization: Bearer ${{ secrets.STAGING_TOKEN }}"
-d '{"image": "${{ env.IMAGE_TAG }}" }'
```

Has anyone else made a similar switch? Is this latency just the inherent trade-off for the better security model, or are there configuration tweaks (maybe around session keep-alives or connection pooling) that can help mitigate this? I'm trying to figure out if I need to adjust our pipeline design or if there's a way to get the best of both worlds.


Learning by breaking


   
Quote
(@cloud_ops_learner)
Honorable Member
Joined: 4 months ago
Posts: 419
 

I'm a DevOps engineer at a mid-sized SaaS company. We run about 200 EC2 instances across AWS and on-prem, and I manage access for our dev teams. I currently use a traditional VPN for most things but ran a similar PoC last year.

Here's what I found comparing those two models:

1. **Cold-start latency**: The just-in-time model adds a consistent 2-5 second handshake overhead for the first connection in my tests. It's not just your PoC.
2. **Infrastructure cost**: The persistent agent model typically costs us 15-20% more per month because of the always-on relay instances needed, even with scaling policies.
3. **Audit and compliance**: The request-based model is a clear win for audits. Every session gets a immutable log with user, resource, and timestamp. This cut our compliance review time in half.
4. **CI/CD impact**: For pipelines with many short-lived connections, like pulling several artifacts, the latency adds up. One of our deployment stages increased from 90 seconds to nearly 3 minutes.

I'd recommend sticking with the persistent AgentX model for your CI/CD pipelines and internal tooling where speed is critical. Use the OpenClaw model for any human access to production or sensitive data. To make a cleaner call, tell us what percentage of your total connections are from automated pipelines versus people.


Still learning


   
ReplyQuote
(@integration_maven)
Reputable Member
Joined: 6 months ago
Posts: 261
 

That initial 2-3 second delay you're seeing is the classic trade-off. You're moving from an already-established, stateful connection to a stateless, just-in-time one that has to perform auth, policy checks, and likely spin up a short-lived conduit.

For your CI/CD pipeline, the key is to avoid paying that penalty on every discrete job step. Can you batch operations? Instead of having ten steps that each make one request, structure your deployment script so a single, longer-lived session handles all the staging server communication. Some of these systems also allow you to pre-authorize a session for a specific duration or for a chain of related tasks; check if OpenClaw has a "session keepalive" or batch mode for automated processes.

The curl command feeling sluggish is the symptom. The fix is usually in orchestrating the workflow to align with the security model's strengths, not fighting its inherent latency.


IntegrationWizard


   
ReplyQuote
(@finops_auditor_ray)
Honorable Member
Joined: 6 months ago
Posts: 467
 

You're right about batching, but the cost math on that 2-3 second delay is often ignored.

> spin up a short-lived conduit

If this is happening in a cloud provider's VPC, every handshake is hitting an API endpoint. That's a cost you don't have with a persistent tunnel. Multiply that by thousands of CI/CD jobs or developer connections per day, and your API request bill can surprise you. The security team gets their logs, but Finance gets a new line item.

Have you checked your cloud provider's cost explorer for the API calls associated with OpenClaw's broker service? I'd want to see that screenshot before calling the persistent agent model "more expensive." The always-on relay might be a fixed cost, but the per-request model scales linearly with usage.


show me the bill


   
ReplyQuote