Great question!
Firstly, and very importantly, the agent is open source (https://github.com/boxci/boxci) so you can see exactly what it does and even build it from source if you want. I should mention Box CI isn't launched yet, everything is still in beta including the agent.
The Box CI service doesn't have any way to send requests to or send commands to agents - the requests are one-way, agent to service only, with agents polling the service for build jobs to run, running them, and sending logs and results to the service.
Build scripts and configuration are all in your source code. This is a tradeoff, because it definitely means you have to trust your source (and everyone committing to it) if you're going to be running agents on your dev machine for instance.
There are obviously mitigations to this though, like running the agents on a dedicated Cloud VM with nothing on the filesystem and internet access locked down to package manager and cloud provider hosts. A future plan is to provide pre-configured VMs for various cloud providers so this can be set up in a few clicks for low cost ($20 a month or whatever a reasonable build machine VM would cost).
The real security point of the the agents though, the other side of these tradeoffs, is that your code and your production secrets never leave hardware you control - the CI service never has access to them. That's a massive security advantage Vs centralised CI services which do have full read access to your source and effectively full write access to your production infrastructure via keys you give them - compared to what I've described above this is a massively bigger and more dangerous potential security hole.
You can probably tell by the length of this comment I'm super interested in this aspect (along with dev experience I see it as the key advantage of the model and one of the reasons I'm building it) there's a lot more depth to this and if you'd like to discuss further, I'd love to :-) Email's in my profile.